Centralized Third-Party Routing Server - AudioCodes Mediant 3000 User Manual

Parameter
Port
[HTTPRemoteHosts_Port]
Interface
[HTTPRemoteHosts_Interf
ace]
Transport Type
[HTTPRemoteHosts_HTTP
TransportType]
Status

16.5.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. The routing server can be used to
handle SBC and Tel-to-IP Gateway calls.
Employing a routing server replaces the need for using the device's routing tables for
determining the destination of calls (IP-to-IP Routing table for SBC calls and Tel-to-IP
Routing table for Tel-to-IP calls). When the device receives an incoming call (INVITE), if an
appropriate matching routing rule exists in the routing table which is configured to use a
routing server, instead of routing the call according to the routing table, the device sends
the call information to the routing server and the routing server determines the call routing
path to the destination. The routing server uses its own algorithms and logic in determining
the best route path. The routing server manages the call route between the devices in
"hops", which may be spread over different geographical locations. The destination to each
hop is by IP Group and/or Trunk Group (other destination types may be supported in the
future, such as IP addresses). Once the device receives the resultant destination hop from
the routing server, it sends the call to that destination.
Upon an incoming call, the device requests the routing server for the next routing hop (next
device) and when a response is received from the routing server with the appropriate hop,
the device routes it accordingly. This 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 which 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. This enables the routing server to uniquely identify requests belonging to the same
call session.
User's Manual

FQDN resolution is also performed (immediately) when connection
is subsequently "closed" (by timeout or by the remote host) and
connections are updated accordingly. In addition, the device
periodically (every 15 minutes) performs DNS name resolution to
ensure that the list of resolved IP addresses has not changed. If a
change is detected, the device updates its' list of IP addresses and
re-establishes connections accordingly.

In addition to multiple HTTP sessions, the device establishes
multiple (TCP) connections per session, thereby enhancing data
exchange capabilities with the host.
Defines the port of the host.
The valid value is 0 to 65535. The default is 80.
Assigns one of the device's IP network interfaces through which
communication with the remote host is done.
By default, no value is defined and the OAMP interface is used.
Defines the protocol used for communicating with the host:

[0] HTTP (default)

[1] HTTPS
Read-only field displaying the status of the connection.

"Connected": The hosts is connected.

"Disconnected": The host is disconnected.

"Not In Service": Configuration of the host is invalid.
284
Description
Document #: LTRT-89730
Mediant 3000