Close this search box.

AudioCodes SBC – Alternative Routing configuration

When doing configuration for larger sites, we often end up in scenarios with several call termination points. What could be a swift and easy configuration can often become ugly in configuration but also unnecessarily complex from a design perspective of the SBC.

Let’s say customer “A” has a Microsoft Teams direct routing solution and wants to integrate it with a third-party DECT solution for their warehouses. The number termination has to end up in both Teams and the DECT solution with mixed numbers. Depending on the amount of active numbers, this could result in many entries in your IP-to-IP routing table.

A great way to overcome this is by using alternative routing, an option in the AudioCodes SBCs.

So what is alternative routing, and how is it configured?

Before we dig into how this is configured, let’s review the actual functionality. So, alternative routing lets you route calls to alternative destinations based on SIP response codes. One scenario could be incoming calls from PSTN which could potentially have two destinations. The DECT solution or Microsoft Teams. Instead of defining what number ranges go where(which would add administrative tasks if users would change numbers), we can route the calls based on the SIP response code, which usually is 404, “user not found.” Instead of terminating the call, we can route it to the next destination.

As you can imagine, this can save quite some time configuring the IP-to-IP routing table and save you from an administrative hell in the future.


To use alternative routing, you must visit two locations and enable it beside the actual configuration in the IP-to-IP routing table. In the proxy set table, you must enable Proxy Hot Swap. Go to the Proxy-set you that is set up to your IP group, and enable Proxy Hot Swap under Redundancy.

The IP group has the configuration of the actual Alternative Reasons Set you plan to use. So, this is the set of SIP response codes that will be used to determine if the Alternative route will be used or not. Further down this article, I will show you how to configure the Alternative Reason set.

Go to your IP group and edit it. Scroll down to SBC Advanced, and choose your Alternative Routing set as shown here.

IP to IP routing configuration

Now that we have enabled Alternative Routing for the IP group, we will start configuring the routing table.

We will use the following three options for our scenario.

Route Row

This is the entry point for our routing. This will be the first route, preferred route, or whatever you want to call it. You can define several different characteristics to match the specific incoming call. This could be source or destination numbers, hosts, or tags. The Route Row must be the top route to trigger the Alternative Routes.

Alternative Route Consider Inputs

If the first row fails to match the call, we can start working with alternative routes. This option looks at the SIP dialog and matches what you have specified in the filter. This could be SIP response code 4xx, 5xx, or, more specifically, codes like 404, “user not found,” which is a good example for us in our scenario.

Alternative Route Ignore Inputs

This is a safety net. If you do not want any dropped calls, this option can help and route to another destination like a reception or call queue.

Alternative Routing Reason Set

The Alternative Routing Reason Set defines what SIP responses to look for before routing calls. To configure these options, log into the SBC and navigate to “Setup” and “Signaling & Media,” open SBC and Routing.

Clicking on New, you get to name your new Alternative Reasons set. Now we can start defining what SIP response codes we will look after before routing.

Click on the “Alternative Reasons Rules 0 Items” hyperlink and “New” to start adding SIP response codes.

As you can see in the following image, we have the option to look at a wide range of SIP responses. We can narrow things down to specific response codes as well. You may want one destination for SIP response codes 404 and 484, while you want to send 5xx in a different direction. This can be useful in high-availability setups for call rerouting if a WAN or LAN connection is marked down.

IP-to-IP routing table

Now that the hard work is done, it’s time to glue it all together in a working routing scenario. This is the IP-to-IP routing table overview. We will focus on the inbound calls and how they are routed to each entity. As we will rely on the SIP response codes for routing, there is no need to specify number ranges or hosts. We can simply send everything from the SIP trunk, to the first routing point.

The next routing point is the DECT solution. If Teams return a SIP response code of 4xx or 5xx, the call will continue to the alternative routing point.

To add a bit of complexity and to state the point of how this works, I have added another route entry which will send all calls with the SIP response of 5xx and 403 to another SBC for redundancy. This step is important only to use SIP response codes that actually state an outage. So service is unavailable, which is the 5xx range, and I have added 403 forbidden, as this was the indication from the DECT solution that one of its interface cards was offline.

Any other call which does not fall into any of these categories is dropped, as the route table ends here.


Using alternative routing on your AudioCodes SBC is pretty powerful, and it could save you much time tampering with data in your routing tables. It’s easy to set up, and it will remove much hard work from the administrator. Let’s face it; when an AudioCodes SBC is installed and configured, it is not something you touch very often. Why not make it as simple as possible, which in the end, will reduce time spend on adding configuration or troubleshooting.

I won’t talk about documentation, but yeah, it is always a good thing to document your work. 😊

Leave a Comment