Utilizing redundant SIP trunks with Asterisk

I just signed up with a new SIP trunk provider that has three SIP trunk registrations (a primary, secondary, and tertiary).

The idea is, send all outbound calls to the primary SIP trunk; however, if that trunk is down for whatever reason, send that outbound call to the secondary trunk instead.

I have all three trunks registered fine and can manually send calls out each of them; however, I haven’t been able to find a solution for an automatic timeout if the trunk is unable to handle an outbound call.

Anyone have any ideas? Is it as simple as a timeout in the dial plan somehow?

Trunks are software concepts (and actually not an Asterisk one). Three trunks going to the same hardware will all fail together, so I hope that your three trunks actually go to three different computer centres, over diverse routes.

You would use qualify to detect when a “trunk” was down. A dial timeout wouldn’t be much use, as that is timing out humans. The standard SIP protocol will time out if there is no SIP response. You can use RTP timeouts, to detect media failure, but it is then too late for rerouting.

Thanks for your response.

You are correct, redundant trunks to the same destination would be useless. These are three separate trunks to 3 separate data centers (in separate geographical locations).

I understand that I’ll know when the trunk goes down by using qualify, but I’m looking for more of an automatic failover type of reaction from the system. I don’t want to manually redirect calls to different trunks if one were to go down.

The simplest way is to write the fail over on the dial plan

Example With 2 trunks :
exten=>_x.,1,Dial(SIP/${EXTEN}@Trunk1)
same=>n,Gotoif($[${DIALSTATUS}=CHANUNAVAIL]?continue)
Same=>n(continue),Dial(SIP/${EXTEN}@Trunk2)

Or could be like this

exten=>_x.,1,Dial(SIP/TRUNK1/${EXTEN})
same=>n,Dial(SIP/TRUNK2/${EXTEN})
same=>n,Dial(SIP/TRUNK3/${EXTEN})

Thanks for the post, I will give that a try.

Generally you need to analyse the SIP cause or hangup cause, to determine whether the fault is likely to be in the network or at the destination; you don’t want three missed calls instead of one.

I didn’t mention the dialplan handling of a failure, because you were asking about detecting timeouts, not what to do when you have one.