Centralized Routing by ARM (AudioCodes Routing Manager)
You can employ ARM
For more information on ARM, refer to the documents ARM User's Manual and ARM Installation Manual
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 ARM ('Destination Type' parameter configured to Routing Server), the device sends a request to ARM 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 ARM for an appropriate destination.
The request is sent to ARM using an HTTP Get Route message. The request contains information about the call (SIP message)
ARM uses its own algorithms and logic in determining the best route path. ARM manages the call route between devices in "hops", which may be spread over different geographical locations. The destination to each hop (device) can be an IP address (with a port) or IP Group
Once the device receives the resultant destination hop from ARM, it sends the call to that destination. ARM 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), ARM cannot find an appropriate route for the call or it doesn't respond, for example, due to connectivity loss (i.e., ARM 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 ARM responds with an HTTP 404 "Not Found" message, the device rejects the call.
This HTTP request-response transaction for the routing path occurs between ARM 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 ARM, which responds with the next hop in the route path. Each device considers the call as an incoming call from an IP Group
Communication between the device and ARM is through the device's embedded Representational State Transfer (RESTful) API. The RESTful API is used to manage the routing-related information exchanged between ARM (RESTful server) and the device (RESTful client). When you have configured the device with connection settings of the routing sever or ARM and the device starts-up, it connects to ARM and activates the RESTful API, which triggers the routing-related API commands.
The following figure provides an example of information exchange between devices and ARM for routing calls:
ARM can also manipulate call data such as calling name, if required. It can also create new IP Groups and associated configuration entities (e.g., IP Profiles), if necessary for routing. Multiple ARM instances can also be employed, whereby each device in the chain path can use a specific ARM instance. Alternatively, a single ARM can be employed and used for all devices ("stateful" ARM server).
The device automatically updates (sends) ARM with its' configuration topology regarding SIP routing-related entities
In addition to regular routing, ARM also supports the following:
| ■ | 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 ARM, sends a new routing request to ARM. ARM 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 ARM sends an HTTP 404 "Not Found" message for an alternative route request, the device rejects the call. If ARM is configured to handle alternative routing, the device doesn't make any alternative routing decisions based on its alternative routing tables. |
If the device sends an HTTP Get Route request and ARM responds with a REST API attribute "action" that is set to the value 'continue', the device routes the call using its IP-to-IP Routing table. It uses the routing rule located after the original routing rule used to query ARM ('Destination Type' set to Routing Server) whose 'Alternative Route Options' parameter is configured to Route Row. This routing can be used at any stage of the call (e.g., after alternative routing failure by ARM, or after receiving a REFER/3xx).
| ■ | Call Forking: The device can fork calls according to ARM. 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 ARM. When it receives a successful response from the server or ARM, the device sends an INVITE message to a destination based on the response. If the routingMethod in the response from ARM is "fork", the device sends another HTTP Get Route request to the server or ARM 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 ARM, or it is set to “seq”, or there is a failed response from the server or ARM. If all the contacts fail (4xx), the device falls back to an alternative route, if exists, from ARM. If 3xx is received for any of the forked destinations, the device handles it after all the forked INVITEs have been terminated. |
ARM can also provide the device with a "no-answer timeout" in the response. If the called IP party doesn't answer the call within this interval, the device disconnects the session or forks the call (delayed call forking). If provided, this value overrides the [SBCAlertTimeout) parameter
| ■ | Call Status: The device can report call status to ARM to indicate whether a call has successfully been established 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: ARM 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, ARM sends the credentials only to the last device ("node") in the path. |
Alternatively, the device can authenticate incoming SIP requests (INVITE or REGISTER) from User-type IP Groups, by first obtaining (REST-based API query) the user's password from ARM where it is stored. When this feature is enabled and the device receives an incoming SIP dialog-initiating request, it sends the REST API command getCredentials in the Get request to ARM. The name of the user whose credentials are requested is obtained from the SIP From header when authenticating an INVITE message, and from the To header when authenticating a REGISTER message. ARM sends a 200 response to the device containing the password (if the requested user exists). The device then sends the challenge back to the user. The user resends the request with a SIP Authorization header (containing a response to the challenge), and the authentication process continues in the usual manner. If the device doesn’t receive a password, it rejects the incoming dialog (SIP 404). To enable this authentication type, you need to configure the IP Group's 'SBC Server Authentication Type' parameter to ARM Authentication (see Configuring IP Groups). Note that ARM doesn't authenticate users, but only helps the device to process the SIP Digest authentication by providing the user credentials.
| ■ | QoS: The device can report QoS metrics per IP Group to ARM which it can use to determine the best route (i.e., QoS-based routing). For more information, see Configuring QoS-based Routing by ARM. |
| ■ | Call Preemption for Emergency Calls: If you enable call preemption for emergency calls (e.g., 911) on the device, ARM 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 [SBCPreemptionMode] parameter |
| ■ | Registration status: The device can periodically synchronize its registration database of SIP user agents (endpoints) with ARM to keep it up to date, enabling ARM to use this information to perform correct and optimal routing decisions. To enable this functionality, see Enabling Registration Status Services. |
| ➢ | To configure routing based on ARM: |
| 1. | For each configuration entity (e.g., IP Group or IP Profile) that you want routing done by ARM, 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 Local Management User Accounts) that is used by ARM (REST client) to log in to the device's management interface. |
| 3. | Configure the address and connection settings of ARM, referred to as a Remote Web Service and an HTTP remote host (see Configuring Remote Web Services). You must configure the 'Type' parameter of the Remote Web Service to Routing, as shown in the example: |
| 4. |
|
| 5. | (Gateway Application Only) Open the Routing Settings page (Setup menu > Signaling & Media tab > Gateway folder > Routing > Routing Settings), and then enable routing by ARM, by selecting the 'Gateway Routing Server' check box (GWRoutingServer): |
