asterisk users - Apr 2005 - if outgoing call fails with provider 1 then auto try provider 2

When someone teminates a call with my softphone to my
asterisk server i want asterisk to try provider 1
first and if the call does not go through because the
provider is having problems then it will try provider
2 gracefully.

I realize that "the provider is having problems"
statement is hard to descrribe. There could be so many
problems! For example:

1) an account password got changed. 
2) account was accidentally disabled. 
3) network problems of any kind. 
4) "constant busy"(I have heard of this happening
sometimes?) 
5) "iax2 show peers" show them having a problem.
6) use your imagination, there are lots more


I have searched the wiki and other sources and cannot
find an extensions.conf example that will accomplish
this. If someone can post an exapmle I will add it to
the wiki. I am trying to make things as bulletproof as
possible. Thanks, Tom


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

On April 22, 2005 10:38 pm, Thomas Miller wrote:
> When someone teminates a call with my softphone to my
> asterisk server i want asterisk to try provider 1
> first and if the call does not go through because the
> provider is having problems then it will try provider
> 2 gracefully.
This is a simple dialplan macro and context that will try to call through 
nufone and, failing that, dial through my PRI.  It takes two arguments.  

${ARG1} = number to call, no leading 1 or 0.
${ARG2} = optional account code for billing.

It needs to be expanded upon.  I plan on adding a little AstDB lookup to force 
an immediate failover and some other undisclosed magic to periodically test 
the connection through nufone's echo username.  Also with a proper rate 
engine you can dynamically determine the order of VOIP providers to try.  
It's really not too difficult once you understand contexts, context ordering
and have a little experience under your belt.

All my "final path" macros work this way and have trivial little
dialplan
contexts to route the call to the macro.  The only gotcha is in 
${DIALSTATUS}=CONGESTION -- If Dial() can't reach an IAX client it will 
return CONGESTION, and my argument is that CONGESTION should *only* be 
returned by Dial() if the far end SAYS it's congested.  The inability to 
reach a destination should return CHANUNAVAIL.  I will post a patch to fix 
this one of these days.

Of course to "chain" providers, you simply
Macro(nextprovider-dial,${ARG1},
${ARG2}) and so on and so on; I only use Nufone and fall through to the PRI, 
so that's what you see here.  If the PRI fails there are bigger 
troubles.  :-)

The dialplan snippet that follows works too well; I need to add some logging 
and alerting because I've had calls fail through and dial out my PRI (at my 
telco's full LD rate) for a full week before I realized that my nufone 
settings had changed; the dialplan just seamlessly routed the calls to the 
failover, which is *exactly* what it should have done.  :-)

In your dialplan proper you will have your context that users can dial long 
distance (and international) through.  You simply include => nufone to have 
it attempt to dial nufone in the right order that you want it to be attempted 
in.

Example:
[trunk-ld]
exten => _NXXNXXXXXX,1,Macro(pri-dial,${EXTEN})
exten => _1NXXNXXXXXX,1,Macro(pri-dial,${EXTEN:1})

[trunk-int]
exten => _011.,1,Macro(pri-dial,${EXTEN})
exten => _1011.,1,Macro(pri-dial,${EXTEN:1})

[nufone]
exten => _NXXNXXXXXX,1,Macro(nufone-dial,${EXTEN})
exten => _1NXXNXXXXXX,1,Macro(nufone-dial,${EXTEN:1})

[nufone-int]
exten => _011.,1,Macro(nufone-dial,${EXTEN})
exten => _1011.,1,Macro(nufone-dial,${EXTEN:1})

; longdistance dialplan.  Order is top-down and implies cheaper paths above 
more expensive ones.
[longdistance]
include => local
include => voctel
include => nufone
include => trunk-ld

[international]
include => longdistance
include => nufone-int
include => trunk-int

[trusted]
include => nine11
include => international

[macro-nufone-dial]
exten => s,1,GotoIf($[$ACCOUNTCODE != ""],s,gotac)
exten => s,n,SetVar(ACCOUNTCODE=${ARG2})
exten => s,n,GotoIf($[{$ARG2} != ""],s,gotac)
exten => s,n,SetVar(ACCOUNTCODE=benshaw)
exten => s,n(gotac),SetAccount(${ACCOUNTCODE})
exten => s,n,GotoIf($[${LEN(${ARG1})} = 10]?s,add1)
exten => s,n,Dial(IAX2/username@nufone-1/${ARG1},,g)
exten => s,n(postdial),NoOp(NUFONE: HANGUPCAUSE is ${HANGUPCAUSE} and 
DIALSTATUS is ${DIALSTATUS})
exten => s,n,Goto(dial-${DIALSTATUS},1)
exten => s,n(add1),Dial(IAX2/username@nufone-1/1${ARG1},,g)
exten => s,n,Goto(postdial,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,Macro(pri-dial,${ARG1},${ARG2})
exten => dial-CHANUNAVAIL,1,Macro(pri-dial,${ARG1},${ARG2})

-A.

> When someone teminates a call with my softphone to my
> asterisk server i want asterisk to try provider 1
> first and if the call does not go through because the
> provider is having problems then it will try provider
> 2 gracefully.
> 
> I realize that "the provider is having problems"
> statement is hard to descrribe. There could be so many
> problems! For example:
> 
> 1) an account password got changed. 
> 2) account was accidentally disabled. 
> 3) network problems of any kind. 
> 4) "constant busy"(I have heard of this happening
> sometimes?) 
> 5) "iax2 show peers" show them having a problem.
> 6) use your imagination, there are lots more
> 
> 
> I have searched the wiki and other sources and cannot
> find an extensions.conf example that will accomplish
> this. If someone can post an exapmle I will add it to
> the wiki. I am trying to make things as bulletproof as
> possible. Thanks, Tom
There are no real examples that would address your points. The
primary reason is that your * can dispatch a call to a provider
and the provider will accept that handshaking call. But, if
they are having internal call-completion issues, there is no
way for you to know that. You could get some sort of busy,
dead air, etc.

You could probably design some sort of timer-based timeout,
but what indication would you use to indicate the call was
successful vs unsuccessful?

There are several ways to address whether your * is successful
in reaching your provider's equipment, but that's about it.

Rich- wouldn't Andrew K's solution work? That seems to
make good sense.
> 
> There are no real examples that would address your
> points. The
> primary reason is that your * can dispatch a call to
> a provider
> and the provider will accept that handshaking call.
> But, if
> they are having internal call-completion issues,
> there is no
> way for you to know that. You could get some sort of
> busy,
> dead air, etc.
> 
> You could probably design some sort of timer-based
> timeout,
> but what indication would you use to indicate the
> call was
> successful vs unsuccessful?
> 
> There are several ways to address whether your * is
> successful
> in reaching your provider's equipment, but that's
> about it.
> 
> 
> _______________________________________________
> 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
> 
__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Thanks Andrew for the great example! Anybody else have
any input?

Tom
--- Andrew Kohlsmith <akohlsmith-asterisk@benshaw.com>
wrote:
> On April 22, 2005 10:38 pm, Thomas Miller wrote:
> > When someone teminates a call with my softphone to
> m

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