[asterisk-dev] SIP call-limit and Realtime

[Johansson Olle E]

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).

For device states, I think we need a special "dbhint" that looks up
the hint in the realtime database, aggregated from all the servers.

Anyway, the current system is not a good solution and is in
desperate need of some attention.

/O