CHAPTER16 Services
Mediant 800 Gateway & E-SBC | User's Manual
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. The Routing server can be used to handle
SBC, Tel-to-IP, and IP-to-Tel calls. Employing a Routing server replaces the need for the device's
routing tables--IP-to-IP Routing table for SBC calls, and Tel-to-IP Routing table and IP-to-Tel
Routing table for Tel-to-IP and IP-to-Tel calls respectively--to determine call destination.
For SBC calls, 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. If the routing rule is configured to
use a Routing server ('Destination Type' parameter is configured to Routing Server), the device
sends a request to the Routing server for an appropriate destination.
For Gateway calls, when the device receives an incoming call (SIP INVITE, NOTIFY or
MESSAGE), it disregards the routing tables and instead, immediately sends a request to 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) and for IP-to-Tel calls, the source IP Group
based on the associated Proxy Set.
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 or Trunk 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 or Trunk 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.
The following figure provides an example of information exchange between devices and a Routing
server for routing calls:
- 266 -
To Next Page
Loading...
Need help?
General
