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. /O _______________________________________________ --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
