Outbound routes and trunk sequence - how to setup owerflow contitions?

I have outbound route with two trunks in sequence, all the calls are using the 1st primary trunk. Te 2nd trunk is a backup when the 1st trunk is bussy or down.

My problem is that the provider of 1st trunk is in some error cases responding to me with 603 Decline and my box is not overflowing the call to the 2nd trunk so my question is - is there any way in FreePBX how can I force the overflow also in case of 603 message is received? Or can I setup the owerflow on basis of Q.850 header which could be also send by the carrier?

Thanks a lot for any suggestions,


The answer is probably not but if you want to provide a trace for further analysis then I may be wrong.

Currently, if we get back a BUSY from a carrier then we don’t try any more trunks since the carrier is signaling to us that the party is in fact busy.

If we get back a CONGESTION then we carry on and try other trunks, and there are other cases where we further examine the HANGUPCAUSE.

So … if we are mis-interpreting the HANGUPCAUSE then it would be a bug which we could change. In most cases, some SIP carriers are simply signaling incorrectly. If you are being declines because you are using too many channels, then that is something you can control. You simply need to set a Max Channels on the trunk, and if the carrier includes inbound calls in your trunk limit, then you can count inbound calls also buy configuring your “context=” to a auto-configured context that you can determine by checking the tooltip for Max Channels on your trunk.

The problem here is likely how Asterisk might be interpreting a 603. I believe they assume it came from the callee and that the callee declined the call, which would be properly treated as a busy. It’s probably open to interpretation but in most cases, it’s probably correct. It would probably be more appropriate for the provider to send a 503 but…

Feel free to paste the CLI output of the failed call to see what is actually being executed in case it sheds any more light. Here is the basic logic today that is used to decide what to do. It only attempts another call if it goes off to the “continue” extension:

exten => s,n,Noop(Dial failed for some reason with DIALSTATUS = ${DIALSTATUS} and HANGUPCAUSE = ${HANGUPCAUSE})
exten => s,n,Goto(s-${DIALSTATUS},1)
exten => s,n(chanfull),Noop(max channels used up)
exten => s-BUSY,1,Noop(Dial failed due to trunk reporting BUSY - giving up)
exten => s-BUSY,n,Playtones(busy)
exten => s-BUSY,n,Busy(20)
exten => s-ANSWER,1,Noop(Call successfully answered - Hanging up now)
exten => s-ANSWER,n,Macro(hangupcall,)
exten => s-NOANSWER,1,Noop(Dial failed due to trunk reporting NOANSWER - giving up)
exten => s-NOANSWER,n,Progress
exten => s-NOANSWER,n,Playback(number-not-answering,noanswer)
exten => s-NOANSWER,n,Congestion(20)
exten => s-INVALIDNMBR,1,Noop(Dial failed due to trunk reporting Address Incomplete - giving up)
exten => s-INVALIDNMBR,n,Progress
exten => s-INVALIDNMBR,n,Playback(ss-noservice,noanswer)
exten => s-INVALIDNMBR,n,Busy(20)
exten => s-CHANGED,1,Noop(Dial failed due to trunk reporting Number Changed - giving up)
exten => s-CHANGED,n,Playtones(busy)
exten => s-CHANGED,n,Busy(20)
exten => _s-.,1,Set(RC=${IF($[${ISNULL(${HANGUPCAUSE})}]?0:${HANGUPCAUSE})})
exten => _s-.,n,Goto(${RC},1)
exten => 17,1,Goto(s-BUSY,1)
exten => 18,1,Goto(s-NOANSWER,1)
exten => 22,1,Goto(s-CHANGED,1)
exten => 23,1,Goto(s-CHANGED,1)
exten => 28,1,Goto(s-INVALIDNMBR,1)
exten => _X,1,Goto(continue,1)
exten => _X.,1,Goto(continue,1)
exten => continue,1,GotoIf($["${OUTFAIL_${ARG1}}" = ""]?noreport)
exten => continue,n,AGI(${OUTFAIL_${ARG1}})
exten => continue,n(noreport),Noop(TRUNK Dial failed due to ${DIALSTATUS} HANGUPCAUSE: ${HANGUPCAUSE} - failing through to other trunks)
exten => continue,n,Set(CALLERID(number)=${AMPUSER})