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). For device states, I think we need a special "dbhint" that looks up the hint in the realtime database, aggregated from all the servers. Anyway, the current system is not a good solution and is in desperate need of some attention. /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
