AudioCodes Mediant 4000 SBC User Manual page 290

CHAPTER 16 Services
■ Alternative Routing: If a call fails to be established, the device "closest" to the failure and
configured to send "additional" routing requests (through REST API - "additionalRoute"
attribute in HTTP Get Route request) to the Routing server, sends a new routing request to the
Routing server. The Routing server may respond with a new route destination, thereby
implementing alternative routing. Alternatively, it may enable the device to return a failure
response to the previous device in the route path chain and respond with an alternative route to
this device. Therefore, alternative routing can be implemented at any point in the route path. If
the Routing server sends an HTTP 404 "Not Found" message for an alternative route request,
the device rejects the call. If the Routing server is configured to handle alternative routing, the
device does not make any alternative routing decisions based on its alternative routing tables.
■ Call Forking: The device can fork calls according to the Routing server. When the device
finds a matching routing rule in the IP-to-IP Routing table that is configured with the Routing
Server destination, it sends an HTTP Get Route request to the Routing server. When it
receives a successful response from the server, the device sends an INVITE message to a
destination based on the response. If the routingMethod in the response from the Routing
server is "fork", the device sends another HTTP Get Route request to the server and upon a
successful response, sends another INVITE to another destination based on the response,
and so on. This call forking process continues until no routingMethod is received from the
server or it is set to "seq", or there is a failed response from the server. If all the contacts fail
(4xx), the device falls back to an alternative route, if exists, from the Routing server. If 3xx is
received for any of the forked destinations, the device handles it after all the forked INVITEs
have been terminated.
■ Call Status: The device can report call status to the Routing server to indicate whether a call
has successfully been established and/or failed (disconnected). The device can also report
when an IP Group (Proxy Set) is unavailable, detected by the keep-alive mechanism, or when
the CAC thresholds permitted per IP Group have been crossed.
■ Credentials for Authentication: The Routing server can provide user (e.g., IP Phone caller)
credentials (username-password) in the Get Route response, which can be used by the device
to authenticate outbound SIP requests if challenged by the outbound peer, for example,
Microsoft Skype for Business (per RFC 2617 and RFC 3261). If multiple devices exist in the
call routing path, the Routing server sends the credentials only to the last device ("node") in the
path.
■ QoS: The device can report QoS metrics per IP Group to the Routing server, which the Routing
server can use to determine the best route (i.e., QoS-based routing). For more information, see
Configuring QoS-Based Routing by Routing
■ Call Preemption for Emergency Calls: If you enable call preemption for emergency calls
(e.g., 911) on the device, the routing server determines whether or not the incoming call is an
emergency call and if so, handles the routing decision accordingly (i.e., preempts a non-
emergency call if the maximum call capacity of the device is reached in order to allow the
emergency call to be routed). To enable call preemption for emergency calls, use the parameter
SBCPreemptionMode.
➢
To configure routing based on Routing server:
1. For each configuration entity (e.g., IP Group) that you want routing done by the Routing server,
configure the entity's 'Used By Routing Server' parameter to Used:
2. Configure an additional Security Administrator user account in the Local Users table (see
Configuring Management User
to log in to the device's management interface.
Server.
Accounts), which is used by the Routing server (REST client)
- 257 -
Mediant 4000 SBC | User's Manual