EasyManua.ls Logo

AudioCodes Mediant 4000 SBC - Page 289

AudioCodes Mediant 4000 SBC
1037 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
CHAPTER16 Services
Mediant 4000 SBC | User's Manual
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.
The following figure provides an example of information exchange between devices and a Routing
server for routing calls:
The Routing server can also manipulate call data such as calling name, if required. It can also
create new IP Groups and associated configuration entities, if necessary for routing. Multiple
Routing servers can also be employed, whereby each device in the chain path can use a specific
Routing server. Alternatively, a single Routing server can be employed and used for all devices
("stateful" Routing server).
The device automatically updates (sends) the Routing server with its' configuration topology
regarding SIP routing-related entities SRDs, SIP Interfaces, and IP Groups) that have been
configured for use by the Routing server. For example, if you add a new IP Group and enable it for
use by the Routing server, the device sends this information to the Routing server. Routing of calls
associated with routing-related entities that are disabled for use by the Routing server (default) are
handled only by the device (not the Routing server).
In addition to regular routing, the Routing server also supports the following:
- 256 -

Table of Contents

Other manuals for AudioCodes Mediant 4000 SBC

Related product manuals