asterisk users - Jan 2006 - Fail over to Pri on VoIP connection failure

I am trying to tweak my dial plan and I am running into a problem.
Sometimes my VoIP out bound calls do not complete on overseas calls(busy
or just a hang-up).  Is there a way in the dial plan to automatically
dial out of my PRI when something like this happens.  Either by time
limit by a failure event?

Any point in the right direction would be great

Thanks,


CLI output (cleansed to protect the innocent)

-- Executing Dial("Zap/47-1",
"IAX2/VoIPServicePrividerOUT/011XXXXXXXXXXXX") in new stack
    -- Called VoIPServicePrividerOUT/011XXXXXXXXXXXX
    -- Call accepted by 72.34.43.5 (format g729)
    -- Format for call is g729
    -- Channel 0/23, span 2 got hangup request <----here I get a busy
signal
    -- Hungup 'IAX2/ VoIPServicePrividerOUT-1'



[Outbound context]
exten => _9011.,1,Macro(dialout-trunk,4,${EXTEN:1},) 
exten => _9011.,2,Macro(dialout-trunk,2,${EXTEN:1},)
exten => _9011.,3,Macro(outisbusy)	; No available circuits
exten => _918.,1,Macro(dialout-trunk,2,${EXTEN:1},); 800 numbers to the
PRI
exten => _918.,2,Macro(outisbusy)	; No available circuits
exten => _9Z.,1,Macro(dialout-trunk,4,${EXTEN:1},)
exten => _9Z.,2,Macro(dialout-trunk,2,${EXTEN:1},)
exten => _9Z.,3,Macro(outisbusy)	; No available circuits


Richard

I know this may be a backwards way but for several
reasons I have asterisk send all calls thru astcc.
With astcc you specify multiple routes with prioroty
settings. If it cant complete a call with one route it
will roll over and use the next one.

Regards,
Dovid
--- "Cavanna, Richard" <RCavanna@sychip.com> wrote:
> I am trying to tweak my dial plan and I am running
> into a problem.
> Sometimes my VoIP out bound calls do not complete on
> overseas calls(busy
> or just a hang-up).  Is there a way in the dial plan
> to automatically
> dial out of my PRI when something like this happens.
>  Either by time
> limit by a failure event?
> 
> Any point in the right direction would be great
> 
> Thanks,
> 
> 
> CLI output (cleansed to protect the innocent)
> 
> -- Executing Dial("Zap/47-1",
> "IAX2/VoIPServicePrividerOUT/011XXXXXXXXXXXX") in
> new stack
>     -- Called VoIPServicePrividerOUT/011XXXXXXXXXXXX
>     -- Call accepted by 72.34.43.5 (format g729)
>     -- Format for call is g729
>     -- Channel 0/23, span 2 got hangup request
> <----here I get a busy
> signal
>     -- Hungup 'IAX2/ VoIPServicePrividerOUT-1'
> 
> 
> 
> [Outbound context]
> exten => _9011.,1,Macro(dialout-trunk,4,${EXTEN:1},)
> 
> exten => _9011.,2,Macro(dialout-trunk,2,${EXTEN:1},)
> exten => _9011.,3,Macro(outisbusy)	; No available
> circuits
> exten => _918.,1,Macro(dialout-trunk,2,${EXTEN:1},);
> 800 numbers to the
> PRI
> exten => _918.,2,Macro(outisbusy)	; No available
> circuits
> exten => _9Z.,1,Macro(dialout-trunk,4,${EXTEN:1},)
> exten => _9Z.,2,Macro(dialout-trunk,2,${EXTEN:1},)
> exten => _9Z.,3,Macro(outisbusy)	; No available
> circuits
> 
> 
> Richard 
> _______________________________________________
> --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
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

On Thursday 26 January 2006 10:52, Cavanna, Richard
wrote:
> I am trying to tweak my dial plan and I am running into a problem.
> Sometimes my VoIP out bound calls do not complete on overseas calls(busy
> or just a hang-up).  Is there a way in the dial plan to automatically
> dial out of my PRI when something like this happens.  Either by time
> limit by a failure event?
; call $ARG1 through nufone, failing over to the PRI.
[macro-nufone-dial]
exten => s,1,Dial(SIP/${ARG1}@nufone,,go)
exten => s,n,NoOp(NUFONE: HANGUPCAUSE is ${HANGUPCAUSE} and DIALSTATUS is 
${DIALSTATUS})
exten => s,n,Goto(dial-${DIALSTATUS},1)

exten => dial-CANCEL,1,Hangup
exten => dial-ANSWER,1,Hangup
exten => dial-NOANSWER,1,Hangup
exten => dial-BUSY,1,Busy
exten => dial-CONGESTION,1,Congestion
exten => dial-CHANUNAVAIL,1,Macro(pri-dial,${ARG1},${ARG2})

It really is as simple as that.  :-)

-A.

Andrew,

Thanks for this - I have also been looking for a way to "fail over"
calls to a second SIP path, but;

In the event that the first attempt DOES NOT RESPOND (is down) there has
to be a timeout value to go to the next priority, correct? Otherwise the
channels just sits silent waiting for a response.

I think your macro assumes that you got a response from nufone, but what
if they were dead in the water?

Have I missed something?

Is there a way to modify the relevant SIP timer so if the INVITE is not
ack'd in a specific period of time then the next priority is executed?

Damon
> -----Original Message-----
> From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-
> bounces@lists.digium.com] On Behalf Of Andrew Kohlsmith
> Sent: Friday, January 27, 2006 1:12 PM
> To: asterisk-users@lists.digium.com
> Subject: Re: [Asterisk-Users] Fail over to Pri on VoIP connection
failure
> 
> On Thursday 26 January 2006 10:52, Cavanna, Richard wrote:
> > I am trying to tweak my dial plan and I am running into a problem.
> > Sometimes my VoIP out bound calls do not complete on overseas
calls(busy
> > or just a hang-up).  Is there a way in the dial plan to
automatically
> > dial out of my PRI when something like this happens.  Either by time
> > limit by a failure event?
> 
> ; call $ARG1 through nufone, failing over to the PRI.
> [macro-nufone-dial]
> exten => s,1,Dial(SIP/${ARG1}@nufone,,go)
> exten => s,n,NoOp(NUFONE: HANGUPCAUSE is ${HANGUPCAUSE} and DIALSTATUS
is
> ${DIALSTATUS})
> exten => s,n,Goto(dial-${DIALSTATUS},1)
> 
> exten => dial-CANCEL,1,Hangup
> exten => dial-ANSWER,1,Hangup
> exten => dial-NOANSWER,1,Hangup
> exten => dial-BUSY,1,Busy
> exten => dial-CONGESTION,1,Congestion
> exten => dial-CHANUNAVAIL,1,Macro(pri-dial,${ARG1},${ARG2})
> 
> It really is as simple as that.  :-)
> 
> -A.
> _______________________________________________
> --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

> -----Original Message-----
> From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-
> bounces@lists.digium.com] On Behalf Of Andrew Kohlsmith
> Sent: Friday, January 27, 2006 2:07 PM
> To: asterisk-users@lists.digium.com
> Subject: Re: [Asterisk-Users] Fail over to Pri on VoIP connection
failure
> 
> On Friday 27 January 2006 16:00, Damon Estep wrote:
> > In the event that the first attempt DOES NOT RESPOND (is down) there
has
> > to be a timeout value to go to the next priority, correct? Otherwise
the
> > channels just sits silent waiting for a response.
> 
> That's what the qualify parameter in sip/iax.conf is for.  Never
terminate
> calls without it.  :-)  It won't *guarantee* that you'll never get
dead
> air,
> but it sure goes a long way to ensuring that it happens so
infrequently
> you'll think you misdialed.
> 
> > I think your macro assumes that you got a response from nufone, but
what
> > if they were dead in the water?
> 
> Then qualify would have failed and Dial() would have immediately
returned
> CHANUNAVAIL.
> 
> -A.
OK - starting to make sense now

Qualify=yes for the peer in sip.conf

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?

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?

Couldn't you just;

Exten => ####,1,Dial(SIP/{$exten@peer1}
Exten => ####,2,Dial(SIP/{$exten@peer2}
Exten => ####,3,Congestion(15)
Exnte => ####,4,Hangup

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

All,

	Thanks for the help. Checking on and changing the route based on
dialstatus is the way to go.  

Thanks,