DO NOT SHARE THESE DOCS WITH CUSTOMERS!

This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.

In this section:

Related articles:

Path Check Support Using SIP OPTIONS Ping

Overview

The SBC Core supports the SIP OPTIONS ping feature whereby a SIP OPTIONS request is periodically sent to a pre-configured or FQDN IP peer (IPv4 and IPv6 are supported) to check its status and discover any new capabilities. The OPTIONS request is sent via the Signaling Port of the zone configured for the peer. The From header of the OPTIONS request is populated with the IP address of the Signaling Port used.

This feature verifies peer-to-peer connectivity, and can be enabled in an existing ipPeer object. The frequency of OPTIONS requests is configurable.

If the peer does not respond after a configurable number of consecutive OPTIONS timeouts (1-10), it is declared down and no new calls are sent to this peer. While the peer is down, OPTIONS-based pinging continues. The peer is considered recovered after a configurable number of consecutive successful OPTIONS transactions (1-10). Up to 2,000 peers may be defined in the OPTIONS ping list using IP address, port and zone details. If a peer's port is omitted, 5060 is the default port.

The failureResponseCodes parameter is used in the Path Check Profile and SIP ARS Profile to specify which responses are considered failures. In this way, if the peer responds with values configured as 'failures', then the peer is blacklisted after a configurable amount of retries.

The Path Check Profile is a proactive system where, if the peer is associated with a profile, then OPTIONS request is sent to that peer continuously to monitor its state. If the peer responds, then it is considered as available. If the peer does not respond even after the configured number of retries, then that peer is blacklisted. Alternatively, if the blacklisted peer responds within the configured number of times, then it is considered as available and is removed from the blacklist. Refer to Path Check Profile - CLI or Service Profiles - Path Check Profile (EMA) for configuration details.

The SIP ARS Profile, on the other hand, is a more reactive system. It is triggered when a Trunk Group includes a configured SIP ARS Profile when an INVITE request is sent to the associated peer and the INVITE times out. This also applies for cases where recoveryAlgorithm configuration is set to "probe" (not "timer"). The peer is immediately blacklisted and the job of the OPTIONS is to indicate its availability again. Refer to SIP ARS Profile - CLI or Service Profiles - SIP ARS Profile (EMA) for configuration details.

An administrative state allows the ability to manually blacklist a peer whereby new calls to the peer are only sent if peer is "Up" (from ping state perspective) and "Active" (from administrative state perspective). A broad illustration of this feature is depicted in Figure 1  with the following principal elements:

  • Pathcheck task
  • a client interface or CLI commands
  • a configurable profile controlling the behavior of the pings
  • SIP options

The Path Check Profile specifies the conditions that constitute a connectivity failure, and in the event of such a failure, the conditions that constitute a connectivity recovery.


Note

Ribbon recommends to not configure Path Check Profile and SIP ARS Profile on the same peer to avoid unexpected results. As a general rule, the Path Check Profile is configured on the access leg where there is less traffic, and the ARS Profile is configured on the peer leg where there is continuous traffic. 

Path Check Architecture

Figure 1: Path Check Architecture


The following example call flow reflects failureResponseCodes behavior when Path Check Profile is configured as follows:

  • replyTimeoutCount = 3
  • sendInterval = 60 seconds
  • recoveryCount = 2
  • protocol = sipOptions (default)
  • failureResponseCodes = all5xx

Figure 2: Path Check Profile Example Call Flow 


Path Check Support Using ICMP Ping


The Path Check Ping mechanism verifies peer-to-peer connectivity between the SBC and a target IP.

The SBC supports the following path check functionality using ICMP ping:

  • Use the ICMP to check if the remote entities are reachable. 
  • Generate and send the ping packets based on the configuration. 
  • Run up to 300 ping sessions simultaneously. 
  • Monitor the responses and validates if there is a failure due to specific conditions.

The SBC accepts the following SIP UA interface parameters:

  • Destination ping address for the session

  • Interface and the corresponding interface group that transmits the ping packets

  • Profile name that identifies the pathCheckProfile that is used with that session

  • Reporting address tag that identifies which SIP signaling peer is associated with the ping session

  • Zone ID that identifies the zone to which the signaling peer belongs

  • Address context containing the corresponding Interface Group

The source ping address is optional since the IP address associated with the interface can be used when not provided.

Note

Create User ACL for ICMP if supporting more than 50 sessions.

Note

Configure static routes to reach the target IP address from the interface through which the ICMP pings are generated.

 


  • No labels