[asterisk-dev] SIP call-limit and Realtime

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

>
> 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?

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

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