Custom Routing Server for AudioCodes SBC

damiankozlowski
Dec 22, 2021
4 min read

Anyone who’s ever deployed an AudioCodes SBC is familiar with some of the most common solutions for implementing call routing logic, for example:

Fixed destination based on user patterns.
Dial plan based routing using destination tags.
LDAP (AD) based routing.

The less known and my all-time favourite solution is the Routing Server. It allows for the routing logic to be decoupled from the SBC and moved to an external service. This approach greatly simplifies the configuration of the SBC, especially in large voice networks with multiple integration points such as PBXs, contact centres or ATAs. It allows voice engineers to focus on important things such as SIP interoperability and security whilst keeping the IP-to-IP routing rules simple and standardised.

The routing logic can be developed to address the most unique of requirements. For example: You can create a JavaScript API that will use values from a SIP headers supplied in the body of the POST request, then query a database, apply custom logic (e.g. CLI mask, call divert) and return the destination IP Group name to the SBC.

It is worth noting that AudioCodes has a turnkey solution called AudioCodes Routing Manager which uses the same interface as the 3rd party routing server that we will build in this blog.

In this blog I will create a simple routing server using the Node.js server and integrate it with the AudioCodes SBC. It should be noted that this solution uses AudioCodes proprietary interface and as such, it will not work with other SBC vendors.

Call Routing Flow using Routing Server:

SIP invite is received from the Teams Direct Routing trunk and it's classified to the Teams IP Group.
The “Main Route” IP-to-IP routing rule matches the incoming SIP dialog and sends the HTTP POST request to the routing server.
The routing server responds with the name of the destination IP Group.
The call is routed according to the IP Group name received from the routing server.

Before you start, you will need:

AudioCodes SBC.
Ideally three UAs connected to the SBC. I will use a SIP Trunk for connectivity to PSTN, Teams DR and registered SIP softphone.
Node.js with Express - visit Node Base Project for deployment instructions.
Port TCP 3000 opened inbound from the SBC to the Node.js server.
Port TCP 3000 opened inbound from a PC running Postman to Node server (optional for testing).
Postman application (optional for testing).
SIP softphone (I’m using Jami).

Out of Scope

SBC deployment.
Configuration of Teams Direct Routing, PSTN SIP trunk and SIP registration.
Encryption of HTTP traffic.
Authentication of POST requests to the routing server.

Implementation

Create the API Endpoint

The API endpoint will process HTTP POST requests from the SBC and return JSON object with the destination IP Group name. To demonstrate the overall concept, I created a very simple endpoint with fixed mapping between a called number and a destination IP Group name. In the real world, such API would most likely query a database and apply complex logic e.g. call diverts, cli masking etc.

Create a new route for the API endpoint. In the blogRoutes.js file add the following path:

router.route('/getRoute').post(sbcActionsController.callRouter);

In the sbcActionsController.js add the callRouter function.

Test Endpoint with Postman

Start the Node project and query the newly create endpoint with Postman.

npm run dev

Your response should include destination IP Group name. To simplify this test, I only included necessary values in the request body. When SBC makes the request, the body will include a lot more data (headers, interface details etc.)

Configure the Remote Web Service

The Remote Web Service defines the destination for the HTTP requests, it is used by the IP-to-IP routing rules.

Path: clear the default value.

Type: select RoutingServer.

Login Needed: set to Disabled unless you secured your endpoint with authentication.

Click “HTTP Remote Hosts” at the bottom of the screen and add the Node.js host.

Make sure to choose the correct interface and destination port. You should see the status “connected”.

Common issues:

NAT: If the SBC and the Node.js server communicate over the private IPv4 network and the selected interface has NAT translation rules in place, make sure the chosen port (e.g. 3000) is not within the target port range.
Firewall – make sure that the IPv4 address associated with the selected interface is allowed inbound on the chosen port (e.g. 3000) on the ACL assigned to the server hosting Node.js
TLS – If you are using HTTPS transport, make sure to import trusted root chain for certificated hosted in the Node.js server into the default SBC tls context.

Create IP-to-IP Routing Rules

Create the main routing rule for handling incoming SIP Invites. My setup also includes rules for handling SIP Options, Registrations and rerouting of REFER messages.

Make sure to select Routing Server as Destination Type (this is what triggers HTTP POST requests).

Testing the Routing Server

Now that all the pluming is in place, it’s time to put it all to the test. To verify that the routing works as it should, I will call the registered SIP softphone from the Teams client and forward the call to an external number via PSTN IP Group.

Here’s the relevant portion of the SIP signalling ladder.

For every SIP transaction that matches the routing rules with destination type set to "Routing Server" a getRoute request is sent to the routing server.

Response from the routing server for the initial call setup from Teams.