[asterisk-dev] SIP call-limit and Realtime

[Johansson Olle E]

23 jan 2008 kl. 04.53 skrev Atis Lezdins:

> On 1/22/08, Johansson Olle E <oej at edvina.net> wrote:
>>
>> 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.
>
> Well, they shuold be updated often, so i don't like term "static". I
> was just going to sleep, and idea popped in my head - i think it
> should be somehow similar to realtime queue members (they got updated
> or marked for deletion). You previously mentioned cache cleaning and
> something like "delete" - but i just don't want to agree on term
> static, as it associates with something really "static". In total - I
> think it needs to be "update" rather than "delete".

The term "static" is from the current implementation where we have
dynamic and static objects - I'm referring to the source :-)

/O