On 1/22/08, Johansson Olle E <[EMAIL PROTECTED]> wrote: > > 22 jan 2008 kl. 17.37 skrev Atis Lezdins: > > > On 1/22/08, Johansson Olle E <[EMAIL PROTECTED]> wrote: > >> > >> 22 jan 2008 kl. 15.32 skrev Atis Lezdins: > >> > >>> On 1/20/08, Johansson Olle E <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Work phone: +1 800 7502835 _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
