Centralized Third-Party Routing Server - AudioCodes Mediant 4000 SBC User Manual

15.6.3 Centralized Third-Party Routing Server

You can employ a remote, third-party Routing server to handle call routing decisions in
deployments consisting of multiple AudioCodes devices.
replaces the need for the device's routing tables (IP-to-IP Routing table) to determine call
destination.
When the device receives an incoming call (SIP INVITE, NOTIFY or MESSAGE), it
searches the IP-to-IP Routing table for a matching routing rule that is also configured to
use a Routing server. If found, the device requests the Routing server for an appropriate
destination. The request is sent to the Routing server using an HTTP Get Route message.
The request contains information about the call (SIP message .
The Routing server uses its own algorithms and logic in determining the best route path.
The Routing server manages the call route between devices in "hops", which may be
spread over different geographical locations. The destination to each hop (device) can be
by IP address (with port) or IP Group. If the destination is an IP address, even though the
destination type (in the IP-to-IP Routing table) is an IP Group, the device only uses the IP
Group for profiling (i.e., associated IP Profile etc.). If multiple devices exist in the call
routing path, the Routing server sends the IP address only to the last device ("node") in the
path.
Once the device receives the resultant destination hop from the Routing server, it sends
the call to that destination. The Routing server can provide the device with an appropriate
route or reject the call. However, if for the initial request (first sent Get Route request for
the call) the Routing server cannot find an appropriate route for the call or it does not
respond, for example, due to connectivity loss (i.e., the Routing server sends an HTTP 404
"Not Found" message), the device routes the call using its routing tables. If the Get Route
request is not the first one sent for the call (e.g., in call forwarding or alternative routing)
and the Routing server responds with an HTTP 404 "Not Found" message, the device
rejects the call.
This HTTP request-response transaction for the routing path occurs between Routing
server and each device in the route path (hops) as the call traverses the devices to its final
destination. Each device in the call path connects to the Routing server, which responds
with the next hop in the route path. Each device considers the call as an incoming call from
an IP Group. The session ID (SID) is generated by the first device in the path and then
passed unchanged down the route path, enabling the Routing server to uniquely identify
requests belonging to the same call session.
Communication between the device and the Routing server is through the device's
embedded Representational State Transfer (RESTful) API. The RESTful API is used to
manage the routing-related information exchanged between the Routing server (RESTful
server) and the device (RESTful client). When you have configured the device with
connection settings of the Routing sever and the device starts-up, it connects to the
Routing server and activates the RESTful API, which triggers the routing-related API
commands.
User's Manual 278
Mediant 4000 SBC
Employing a Routing server
Document #: LTRT-40203