A question that comes up from time to time both with customers – and even internally on our own UC team – is how to address failover voice routing with AudioCodes Mediant SBC devices.
In many E-SBC solutions, voice routing and associated failover – like IP routing – is based on routing table order. You would think if you have two identical routing table/statements – it would try the first, and if it failed, it would go down the list to the next. That’s not the case with AudioCodes SBC routing.
In general, for something to fail and need an alternate route, you probably get one of three SIP responses back: 500, 503 or 487. There are more options, but those are typically the ones you get. And you need to tell AudioCodes what to listen for and then what to do afterward to get this all working properly.
Let’s build some rules to capture these reasons.
Okay, if we get a SIP Response as 487, 500, or 503, that’s a legitimate reason to use Alternative Routing. Again, your mileage may vary here.
Now, let’s build/adjust the routes we’ve discussed up to this point and actually give them useful names based on routing scenarios discussed.
Notice Index #2. That’s an SBC routing entry from our internal Lync/Skype (IP Group 1) to our ITSP (Intelepeer – IP Group 2) for 502-751-2108.
Let’s build an identical route with alternative routing options, pointing to the Gateway so it can route out FXO. We want to make sure the call works if the ITSP goes down.
See that? The routing order is correct, ITSP ahead of FXO. So, routing table order matters.
But notice I changed the Alternate route Options to “Alt Route Consider Inputs”. That means if the SIP RESPONSE (input) matches 487, 500, 503, then use this route. Got it?
So, we have a route that should call 502-751-2108 via ITSP. But, if ITSP isn’t available, then 502-751-2108 should be called out FXO. But in our case, specifically, we can’t dial 10 digits out FXO for a local call. We can only call seven digits, so we have to manipulate that for an IP -> Tel call.
This rule is so if a call is routed IP -> Tel destined for 502-751-2108, strip three digits from left to make it 751-2108.
And the routing table should then send 751-2108 out Hunt Group 1 – the FXO Port – based on previous tests.
But, notice the IP-to-Tel Routing Mode is “Route calls before manipulation”. We need to have a 10-digit route for 502-751-2108 so there is a routing destination before our three-digit strip/manipulation.
Make sense? We’re adding more and more complexity and options and rules to our architecture to fit with various use cases.
Let’s test to make sure our ITSP call works properly.
Looks good. Lync/Skype to 502-751-2108 via ITSP (68.68.117.67).
Now, let’s make sure the ITSP fails. Unplug the WAN cable. We can see below the before state; FXO #1 is connected, and LAN #3 is connected for WAN.
After: LAN #3 is dead.
Any calls out should now fail; however, any calls to 502-751-2108 should re-route out FXO after being properly manipulated to 751-2108.
Let’s test that…
Well, FXO #1 picks up. That’s good!
Weird, why don’t we see the “failover” happening here? We know the failover happens. We see it visually because the FXO port goes active. The call happens.
Let’s go back to the syslog/traces in a little more detail.
Okay, the call happens (obviously), but when we scroll down a little more in the traces we see more.
Ah, okay. Alternative Routing happens. This is good. And then we see more.
There it is, Routing Rule #3 (the alternative route to the gateway). And the call goes forward.
Let’s zoom in to see that in a little more detail
Notice the routing takes place – 502-751-2108 is the destination. Then Manipulation happens removing three digits from the prefix turning it into 751-2108. This is exactly as we expected.
Then back to normal/typical routing…
The Syslog/SIP Traces saw all the logic and what happened, but the SIP Flow Diagram doesn’t because the only SIP Flow that actually stood up and tore down was the SIP Flow out FXO.
The rest of all of this was internal E-SBC logic.
Even though this example was specific to handling 10 digits 502-751-2108, this would more likely be used for useful things like 911, or whatever else you deem critical.
Also in this blog we specifically called out ITSP failover to FXO; however, that is not the only use case here. You can extrapolate alternate routing from ITSP to ITSP or inbound calls as well that primarily are answered by Lync/Skype but failover to an FXS line. Be creative.