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 :) Regards, 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
