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 -
Содержание Mediant 4000 SBC
Страница 1: ...User s Manual AudioCodes Series of Session Border Controllers SBC Mediant 4000 SBC Version 7 2...
Страница 40: ...Part I Getting Started with Initial Connectivity...
Страница 48: ...Part II Management Tools...
Страница 113: ...Part III General System Settings...
Страница 118: ...Part IV General VoIP Configuration...
Страница 525: ...Part V Session Border Controller Application...
Страница 654: ...Part VI Cloud Resilience Package...
Страница 663: ...Part VII High Availability System...
Страница 685: ...Part VIII Maintenance...
Страница 759: ...Part IX Status Performance Monitoring and Reporting...
Страница 844: ...Part X Diagnostics...
Страница 888: ...Part XI Appendix...
Страница 1036: ...This page is intentionally left blank CHAPTER 62 Technical Specifications Mediant 4000 SBC User s Manual 1003...