pruning breaks asterisk on high loads at least on all 5 of our servers.
all using different versions and custom. " What you can do is use "sip prune realtime <name>" to remove just the single peer/user from memory. And you can force a reload of that peer from realtime by using "sip show peer <name> load". " On 8/17/05, Damon Estep <[EMAIL PROTECTED]> wrote: > > > It seems that some options are not re-read when caching is on, for > > > example, changing the caller ID value in the sip table has no effect > > > until a reload (or expiration), so at least in some cases > rtcahcefriends > > > makes realtime notsorealtime. > > > > No. It is doing exactly what it says it will, "cacheing". If you > > have > > rtcachefriends turned on, when a peer/user registers the info is > pulled > > from DB and added to the internal (a la 'in memory') list that > chan_sip > > maintains. If you change something in DB after this occurs then your > > changes won't take affect because chan_sip has no need to re-lookup > your > > phones info since the info is already present in memory. > > > > What you can do is use "sip prune realtime <name>" to remove > just > > the > > single peer/user from memory. And you can force a reload of that peer > > from realtime by using "sip show peer <name> load". > > > > If you want pure realtime where chan_sip always pulls from db, > then > > turn caching off. Keep in mind that turning caching off will remove > MWI > > and NAT functionality. > > > > -Matthew > > > What would it take (you, $) to add functionality that is a cross between > caching and not, that is it caches with a flag in the extension, so if > the flag is present realtime will be queried even though the extension > is in cache when a new call comes IN TO that extension. > > Outgoing calls would not really need a re-query unless something about > the provisioning of the phone changes, at which point it would > re-register anyways, right? > > The goal is caching for MWI and NAT but realtime for calling, so the > database is checked on every inbound call in case the dialplan changed, > and the cache updated accordingly. > > Maybe a TTL flag, and when the TTL expires the cache entry stays, but is > re-queried when a dialplan match is found. The admin could then tune the > performance by setting different TTLs, maybe 15 minutes for lightly > loaded systems, 4 hours for heavy loaded systems. > > Dynamic updates take place in whatever timeframe is specified on the TTL > or less. > > Have I missed something, is this functionality already present? > > Damon > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users