[Asterisk-Users] Fail over to Pri on VoIP connection failure

[Damon Estep]

> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-
> bounces at lists.digium.com] On Behalf Of Andrew Kohlsmith
> Sent: Friday, January 27, 2006 2:45 PM
> To: asterisk-users at lists.digium.com
> 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/{$exten at peer1}
> > Exten => ####,2,Dial(SIP/{$exten at peer2}
> > 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