> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:asterisk-users- > [EMAIL PROTECTED] On Behalf Of Andrew Kohlsmith > Sent: Friday, January 27, 2006 2:45 PM > To: [email protected] > Subject: Re: [Asterisk-Users] Fail over to Pri on VoIP connection failure > > On Friday 27 January 2006 16:24, Damon Estep wrote: > > If you have qualify=yes I assume that triggers a sip query to get > > channel capabilities from the peer? What is the qualify timeout? Can it > > be manipulated? > > qualify (for SIP) sends a SIP OPTIONS packet to the peer and waits for a > response. If it does not receive one within 1000ms (by default) and > qualifysmoothing is not enabled, it will flag the peer as UNREACHABLE > which > means that any attempts to Dial() the peer will fail immediately with > CHANUNAVAIL. Asterisk continues to send these "pings" until it receives a > response within the accepted timeframe and once it gets responses again it > will flag the peer as being available once again. > > There are some other tuning parameters which can be used to modify this > behaviour slightly but this is what qualify does in a nutshell.
Since your original hint on qualify=yes have been hunting for the parameter tuning capabilities of this feature - to no avail. Are you aware of any reference anywhere on tuning the qualify frequency and timeout? I assume this (tuning) does not require code changes. Correct? > > > If the goal was strictly to try one provider, and if the channel fails > > qualify, then try the next, is the macro you posted needed? > > Correct. > > > Couldn't you just; > > > > Exten => ####,1,Dial(SIP/[EMAIL PROTECTED] > > Exten => ####,2,Dial(SIP/[EMAIL PROTECTED] > > Exten => ####,3,Congestion(15) > > Exnte => ####,4,Hangup > > Well I've never been a fan of just letting things "fall off the edge" and > expecting them to work reliably. I use the 'g' Dial() option so that I > can > handle failover and call completion correctly or properly -- instead of > just > letting it do "whatever svn trunk deems right at this point" I > specifically > do things based on how the call terminated. It's just a nicer way of > doing > what you've provided, and ends up being more robust to code policy > changes. Sounds like words of wisdom to me :) Thanks a million D _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
