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

Good night,
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