[asterisk-dev] SIP call-limit and Realtime

[Johansson Olle E]

22 jan 2008 kl. 17.37 skrev Atis Lezdins:

> On 1/22/08, Johansson Olle E <oej at edvina.net> wrote:
>>
>> 22 jan 2008 kl. 15.32 skrev Atis Lezdins:
>>
>>> On 1/20/08, Johansson Olle E <oej at edvina.net> wrote:
>>>> This also touches my earlier questions about what realtime SIP
>>>> buddies
>>>> really are.
>>>> Today, we have an unsatisfactory mix between the old sip buddies  
>>>> that
>>>> are classified
>>>> as realtime dynamic objects and the "cached" objects.
>>>>
>>>> The cached objects should really be just another way of loading a
>>>> static object
>>>> in memory and keep it there as long as it is needed - during
>>>> registration for
>>>> peers that register and from first activity and forever for peers
>>>> with
>>>> a host definition.
>>>>
>>>> In addition to that we need cli and manager commands for releasing,
>>>> loading
>>>> and reconfiguring these objects to match the database changes.
>>>>
>>>> People expect the cached realtime objects to be static. They are  
>>>> not.
>>>> And as such, we cannot provide the same services to them today.
>>>>
>>>> I would like to see a cleanup here.
>>>>
>>>> /O
>>>
>>> Olle,
>>>
>>> I see you want some input here, and now i finally got time to write.
>>>
>>> Actually i don't see where realtime cached objects don't behave as
>>> static objects. When enabled rtcachefriends - i got exactly the same
>>> services as static - device state, call limit, etc. So, this is my
>>> point as user - they should be identical - allowing plain config  
>>> file
>>> for small installations and realtime for larger.
>>>
>>> In my opinion - realtime should provide exactly the same  
>>> functionality
>>> as static (even without rtcachefriends). It should keep all it's  
>>> state
>>> in DB, and rely on that information (even if doing queries often).  
>>> For
>>> device states - i believe Mark has some ideas how to implement that,
>>> and i find it really great. So, the only significant problem as i  
>>> see
>>> remains "qualify". I see just one option here - whenever SIP user  
>>> has
>>> "qualify" enabled, it should be added to list of cached "qualify"
>>> structures. Those should be kept by separate thread(s) in channel
>>> driver. Whenever SIP reregisters (or some other SIP event occurs) -
>>> peer information should be re-read from DB, and checked - whether
>>> qualify or some other information was changed in DB.
>>>
>>> Potentially this realtime status keeping could even allow IP  
>>> takeover
>>> and continuation in case of crash. But that's probably too  
>>> futuristic
>>> for now :)
>>
>> So we need a cleanup here. You and I agree that what we need are
>> static objects loaded from realtime storage.
>>
>> The dynamic objects needs to be cleaned up and we need to implement
>> caching - meaning that Asterisk is in control of when we delete the
>> objects (after inactivity, at memory shortage or at christmas -  
>> it's up
>> to the server).
>
> Well, it depends on what you call "static". I think the functionality
> needs to be identical, however i would want changes in realtime table
> to have effect immediately - that's all the purpose of realtime. As i
> understand - you're talking about keeping copy of object in memory all
> the time (and delete on changes), but i'd like load from database
> every time, and keep only necessary things (qualify thread) in memory.
That's very good input. In fact, one step back to non-cached and one
step forward. That's input I need.
>
>
>>
>> For device states, I think we need a special "dbhint" that looks up
>> the hint in the realtime database, aggregated from all the servers.
>
> Hmm, what did you mean by this? Any more details?
I need to think about this a bit more, but we do need a different kind  
of
hint for realtime objects. It's a complicated system as it is. Devices
can't subscribe to extensions without current hints which means
that we need the hint regardless... Weird loop.
>
>
>> Anyway, the current system is not a good solution and is in
>> desperate need of some attention.
>
> Well, i'm not such pessimistic (probably i don't know chan_sip as well
> as you :). From outside i see only two drawbacks that i mentioned
> before - device state and qualify.

Which both really need static objects that stay in memory.

/O