Address Reachability Service

In order to achieve efficient device fail-over to a backup/secondary Application Server, the SBC uses the Address Reachability Service (ARS) to determine if a server is reachable. This allows the SBC to “blacklist” a server IPv4 or IPv6 address if it is deemed unreachable, and address subsequent requests to that destination appropriately. In summary, the ARS interface provides following configurable capabilities:

• Use INVITE requests timeout(s) to determine if an address is unreachable.
• Add unreachable addresses to a ‘blacklist’ file. Once an address is in the blacklist, no new calls are placed to that destination until the address is removed from the blacklist.
• Provide two mechanisms to remove an unreachable server IP address from the blacklist:
• Use OPTIONS request to probe the blacklisted IP address until the server is once again visible (alive).
• Passively remove an address from the blacklist after a pre-configured period of time.
  • View addresses deemed unreachable.
  • Allow configuration of up to 32 ARS profiles and the monitoring of up to 1,023 endpoints.
  • Allow an endpoint to be marked as blacklisted if a 503 with a Retry-After header is received. In this scenario, the recovery mechanism automatically runs a timer for the length specified in the Retry-After Header. For example, a Retry-After duration of ”120” automatically removes the endpoint from the blacklist two minutes after receiving the Retry-After header.
  • Allow an endpoint to be marked as blacklisted if a 503 without a Retry-After header is received at a rate that exceeds a specific number within the defined time interval. 

Internal to the SBC, multiple call processing modules exist; traffic is shared across these modules. An IP Peer is blacklisted only when the same call processing module reaches the configured number of INVITE timeouts within the configured timeout duration (this is not an absolute value). For a single shot call scenario (i.e. lab testing), it may be necessary to gather additional timeouts to see an IP Peer get blacklisted. Once the peer is blacklisted, the same data is available across all call processing modules.

Similarly, when a peer is not blacklisted but is in the process of being blacklisted because of time outs, the ‘show’ command to check ARS Status may give inconsistent results depending upon the call processing module which response first to the command.

An example of CLI command to set an ARS profile is shown below. Each parameter is entered individually for demonstration purposes. It is not necessary to enter these commands separately.

% set profiles services sipArsProfile TestARSProfile blkListAlgRetryAfterType sip-503
% set profiles services sipArsProfile TestARSProfile blkListAlgTimeoutsNumTimeouts 45
% set profiles services sipArsProfile TestARSProfile blkListAlgTimeoutsType sip-invite
% set profiles services sipArsProfile TestARSProfile blkListAlgorithms timeouts
% set profiles services sipArsProfile TestARSProfile blkListAlgTimeoutsDuration 34
% set profiles services sipArsProfile TestARSProfile recoveryAlgorithm probe
% set profiles services sipArsProfile TestARSProfile recoveryAlgTimerDuration 456
% set profiles services sipArsProfile TestARSProfile recoveryAlgProbeMethod sip-options
% set profiles services sipArsProfile TestARSProfile recoveryAlgProbeInterval 78
% set profiles services sipArsProfile TestARSProfile recoveryAlgProbeNumResponses 6
% set profiles services sipArsProfile TestARSProfile recoveryAlgProbeDuration 546
% set profiles services sipArsProfile TestARSProfile  blkListAlgNoRetryAfterDuration 10
% set profiles services sipArsProfile TestARSProfile  blkListAlgNoRetryAfterNum503 5
% commit

Refer to SIP ARS Profile - CLI or Service Profiles - SIP ARS Profile (EMA) for configuration details.

In the example show status...sipArsStatus command below, the endpoint IP address is an IPv6 address:

> show status addressContext ac-1 zone SipZone sipArsStatus

sipArsStatus 2 0 {
    sigPortNum                  2;
    endpointIpAddress           FC00::3200:0:0:241:2;
    endpointIpPortNum           20302;
    endpointArsState            blacklisted;
    endpointStateTransitionTime 2011-12-09T16:25:21.000009Z;

Local Survivable Mode for Calls and Registrations

In the event of loss of connection with the Application Server (AS), the SBC switches to Local Survivable Mode and handles the call processing with limited functionality. It provides local registration support and limited local calling capabilities.

• INVITE
• REGISTER
• SUBSCRIBE
• NOTIFY
• OPTIONS

The ARS blacklists the server for the specific SIP request type for the duration specified in the retryAfter header while allowing the other request types.

The SBC switches to the local survivable mode under the following conditions:

• IP connection to the Application Server (AS) that hosts the registered subscriber is lost or AS is down. This is detected by using Address Reachability Service (ARS) through blacklisting algorithms such as timeouts to OPTIONS or INVITE requests.
• AS is overloaded and cannot process calls or registrations.
• The SBC detects overload mode using enhanced ARS service acting on AS responses with a retryAfter header for the SIP OOD requests.

Registration in local survivability mode works as follows:

• For existing registered endpoints, the SBC locally responds to refresh registers with 200 OK.
• For new registrations of endpoints, the SBC accepts the registrations without authentication.
• For unregistration requests, the SBC drops the registration and stops sending any further requests from that endpoint to the AS even though it becomes reachable.
   

The SBC routes the calls in local survivability mode as follows:

• Routes call between locally registered endpoints using the Local Registration Cache.
• Routes call originating from external gateways (PSTN or SIP) and terminating on locally registered endpoint using local registration cache.
• Route calls originating from the locally registered endpoint and terminating on external gateways (PSTN or SIP).
• Routes the mid-dialog requests for existing calls to the AS, if it is reachable and overloaded.

• Route local calls using user-configured alternate overflow routes that is added in ERE/PSX.

  Note

  These routes may need digit/prefix manipulation with appropriate trunk group and profiles configured to support various call types and endpoint categories.