[asterisk-dev] SIP call-limit and Realtime

[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 :)

Regards,
Atis

-- 
Atis Lezdins
VoIP Developer,
IQ Labs Inc.
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Work phone: +1 800 7502835