Rerouting Calls on Broken RTP

You can configure the Enterprise SBC to perform call rerouting when it does not receive RTP media packets within your configured timeout on the egress side (called side) of the call. If this RTP connection timeout occurs once, the Enterprise SBC sends BYE to the egress party and regenerates a new INVITE towards the next session-agent (SA) configured in the applicable session-agent-group (SAG) to get an alternate route to an alternate destination. This feature applies to SIP audio calls only; multi-mline call flows must have audio mlines only. This feature is only applicable for RTP loss detected over UDP. This feature does not support media loss over TCP or SRTP.

You configure the RTP connection timeout (initial-guard-timer and subsq-guard-timer) in media-manager or realm-config. The default timeout is 300 seconds. If the RTP media guard timer expiry is detected on the ingress side (caller side), the system does not initiate rerouting. In that case, the system disconnects the call on both sides.

If the timeout is detected on the egress side (called side), the Enterprise SBC sends BYE to the egress party and regenerates a new INVITE to a new SA, fetched through a reroute server list configured on the SA.

After detecting the RTP loss from the called side (egress), the Enterprise SBC:

  • Sends a BYE to the called side but does not disconnect the session on ingress. The session continues for the new call to be connected with new available SA.
  • Continues to try other SA from the SAG configuration if there is a 4xx, 5xx failure response or no response received from the new SA tried.
  • Hunts for and sends the further INVITE to the contact provided in the 3xx contact response if it receives 3xx from the new SA after initial call reroute.
  • Continues by trying to reroute the call to additional SAs within the configured SAG group if RTP loss is detected again on the rerouted call. This assumes the reroute server configuration is enabled on that each subsequent SAG SA.
  • Includes a private header (X-SBC-RerouteReason) in the re-INVITE to the caller, which includes the call-id and the “Call re-routed due to loss of RTP media packets” text.
  • Responds with “491 Request Pending” if it receives a reINVITE/UPDATE from the caller while new invite processing is ongoing.
  • Sends a reINVITE to the caller to convey media IP and port information once the new call is successfully established with the new SA.

In response to call failure conditions, the Enterprise SBC:

  • Disconnects the call and clears all the dialogs and session when:
    • It receives no response for the re-invite from the caller side
    • A new-invite is in progress and the caller sends a BYE/CANCEL, the SBC handles the BYE and clears the call along with all resources.
    • The UAC rejects the Re-invite intended to update the media IP/port with 4xx, 5xx or 6xx, the system disconnects the call.
  • Sends a BYE to the caller if it is unable to connect the call with any of the SAs specified in the SAG group.
  • Inserts the reason header “exhausted reroute servers” within a BYE sent to the caller to clear INVITE transactions.
  • Clears the call if it receives a 6xx message.

Configuration

You use two parameters to configure this feature:

  • session-agent, reroute-server—You specify the SAG to which this session-agent applies, define that SAG as a reroute SAG, which enables the reroute feature. The default is null, which results in the system's default Enterprise SBC behavior of issuing a BYE instead of invoking this feature.

    To configure this parameter, you use the same format used to configure a route, such as sag:routeServers.

  • sip-config, reroute-try-threshold-value—You specify the maximum number of reroute calls the system can attempt after detecting RTP loss by this feature. The default is 5.

Important configurations related to SA selection include:

  • The strategy to pick a specific SA is applicable to the session agent group only when the default value is set to Hunt.
  • Oracle recommends using the RoundRobin strategy to avoid trying the same SA every time and for proper resource utilization.
  • Oracle recommends using SAG group with a small number of SAs. Consider SAGs with about 10 SAs. The bigger the size of the SAG with SA list, the more time it will take in processing the call and will have impact on the performance and capacity.
  • sag-recursion must be enabled on the SAG group. If not, the system responds to 4xx and 5xx messages by disconnecting the call.

    The functionality related to stop-sag-recurse, sip-recursion-policy, and stop-recurse will interact with this feature where SBC must stop trying further reroute servers from the configuration after specified conditions are met.

Related Feature Configuration

Related configuration considerations include:

  • subsq-guard-timer and initial-guard-timer—These must be set to enable the timers used by this feature.
  • disable-guard-timer-sendonly—Disables the media inactivity timer, also disables this feature when a call is on hold.
  • mm-in-realm—If enabled along with this new functionality and both the caller and reroute server (new SA) are on the same realm, the system anchors the media flowing between the caller and reroute server.

    If disabled and a call is established between the caller and new SA on the same realm for this feature, the system releases the media. In that case, the media flows directly between the caller and the new SA. Further media inactivity cannot be detected by the system.

  • Ring Back Tone—If RBT is configured, the system plays RBT towards the caller/UAC while the call is rerouted to the new destination SA after RTP loss detection. RBT for RTP loss detection does not act according to configured RBT triggers. Instead, RBT is played as soon as the guard timer expires and stops when the 200 OK for the INVITE of the rerouted call is received.
  • PRACK-interworking—Causes the system to handle and respond to reliable provisional responses received from the reroute server. This feature is applicable only when the initial INVITE from the caller does not include the 100 Rel in supported header.
  • dialog-transparency— Irrespective of dialog-transparency configuration, a new INVITE initiated towards the reroute server after RTP loss will always have a new Call-ID.

Reporting

The system includes CLI statistics implemented to track the total number of dropped calls by destination IP address due to RTP timeout at both the SAG group and system levels. Commands introduced as part of this feature include:

  • show reroute group-stats [SAG name]
  • show reroute rtp-dropped-call-stats [agent name]

You can reset the statistics for this feature using reset all and reset reroute