You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Overview

The SBC Core inter-works seamlessly with different types of endpoints on the access side for the successful call completion. With the increased usage of the SBC in the enterprise domain, it is exposed to work progressively with more endpoints, irrespective of their support for the Secure Real-Time Transport Protocol (SRTP), and/or IPv4 or IPv6 or not, on the same Trunk Group.

The Retry Profile is used to configure a trigger/action rule to specify that when a particular error response code (and optional warning code) is received (the trigger), the SBC performs a fallback action (fallback SRTP to RTP, fallback to IPV4 or fallback to IPV6). The SBC then reattempts an INVITE with the updated Session Description Protocol (SDP) offer based on the action configured for the received error response and warning code.

Note
  • When the retryProfile is configured, it takes precedence over cranback/redirection/maddr handling functionality.
  • When the retryProfile is not associated with the IPTG, the SBC functions with the existing behavior.

SRTP to RTP Fallback Support

For a call from the core network towards the access side, the SBC is expected to use SRTP as the primary option towards the access side:

If the endpoints do not support SRTP:

  • The endpoints accept the call by sending an answer SDP using Real-Time Transport Protocol (RTP). If the SBC is configured to allow fallback to RTP, it retries the call to the same peer using RTP in the offer.
  • The endpoints reject the call with 488 error response. In this case, the SBC matches the received error response in the configured profile. If there is a match and the corresponding action is configured as "Fallback from SRTP to RTP", the SBC retries the call to the same peer with RTP.

IPV4/IPV6 Inter-working Support

When the SBC receives an error response, which is configured on the profile and the corresponding action is configured as fallback:

  • Fallback to IPv4 address, the SBC retries the call to the same peer with IPv4 address to receive the media in the SDP.
  • Fallback to IPv6 address, the SBC retries the call to the same peer with IPv6 address to receive the media in the SDP.

Retry Profile

The functionality of the retryProfile is explained as follows:

  • If there are multiple rules matching a SIP response code,  the exact match of both SIP response code and SIP warning code are executed as a trigger.


    Example:

    triggerActionRule Rule 1
    {
       Response Code: 488
       Warning Code: 301
       Action Set1:
          {
            Fallback from SRTP to RTP
          }
    }
    triggerActionRule Rule 2
    {
       Response Code: 488
       Action Set1:
      {
          Fallback to IPv6
      }
    }     

     

    If initial INVITE is sent with SRTP and IPv4 address and the SBC receives a 488 response code with warning code 301, the trigger action rule 1 is matched and the subsequent INVITE is sent with RTP and IPv4 address in the SDP.

  • If there are multiple action sets for a specific match SIP response code, each action set must be executed serially irrespective of the different error responses received for the subsequent INVITE.
    The execution is stopped when:
    • the SBC receives a 200 OK response or
    • all the action sets for a particular rule (matching initial INVITE) are executed.

    Example:
     

    triggerActionRule Rule 1
    {
       Response Code: 488
       Warning Code: 301
       Action Set1:
         {
          Fallback from SRTP to RTP
         }
       Action Set2:
         {
           Fallback to IPv6
         }
    }     

    If initial INVITE is sent with SRTP and IPv4 address, and the SBC receives a 488 response with warning code 301, the subsequent INVITE is sent with RTP and IPv4 address in the SDP.

    If this INVITE does not receive any successful response, the INVITE is re-sent with RTP and IPv6 address.

  • If multiple actions are configured for an action set, the new INVITE must be sent based on the combination of all the actions specified in the action set.
    Example:
     

    triggerActionRule Rule1
    {
       Response Code: 488
       Warning Code: 301
       Action Set1:
         {
          Fallback from SRTP to RTP
          Fallback to IPv4
         }
    }     

    If initial INVITE is sent with SRTP and IPV6 address, and the SBC receives a 488 response code with 301 warning code, subsequent INVITE is sent with RTP and IPv4 address in the SDP. The subsequent INVITE is sent as a combination of the actions specified in the action set1.

  • If a specific match (SIP response code and SIP warning code) is not found in the retryProfile, the SBC searches for the response code in the profile and the corresponding action is executed.
    Example:

    triggerActionRule Rule1
    {
       Response Code: 488
       Action Set1:
         {
          Fallback from SRTP to RTP
          Fallback to IPv4
         }
    }     

    If initial INVITE is sent with SRTP and IPv6 address, the SBC receives a 488 response code with 301 warning code. As specific match for both response code and warning code is not found in the profile, the next match for the "Response code" is searched and the new INVITE is sent with RTP and IPv4 address in the SDP. 

Call Flows

Scenario 1

When SRTP is configured and the SBC receives an error response for an SRTP offer, it checks the response code against the retryProfile linked to the IPTG. If the response code is configured on the profile with the action as fallBackSrtpToRtp, the SBC retries the call to the same peer with RTP in the offer. If the Retry profile is not configured or the response code is not present in the profile, the SBC functions with the existing behavior.

Call Flow - Scenario 1

Scenario 2

When SRTP is configured and the SBC receives an error response for an SRTP offer, it checks the response code against the retryProfile linked to the IPTG.

If the response code is configured on the retryProfile with the following actions:

  • Fall back to IPv4
  • Fall back SRTP to RTP

The SBC retries the call to the same peer with RTP and IPv4 address in the SDP. If the profile is not configured or the response code is not present in the profile, the SBC functions with the existing behavior.

Call Flow - Scenario 2

 

Configuring SRTP to RTP Fallback on Receipt of 488

Perform the following steps:

Configuring a Retry Profile with Trigger Action Rule

To configure a retryProfile with trigger action rule, execute the following commands based on the action type:

When Action Type is set as fallBackSrtpToRtp:

% set profiles services retryProfile rp1 triggerActionRule 2 sipResponseCode 301 sipWarningCode 333 action 2 actionType fallBackSrtpToRtp
% commit

or

When Action Type is set as fallBackSrtpToRtp and fallBackToIPV4:

% set profiles services retryProfile rp3 triggerActionRule 5 sipResponseCode 300 sipWarningCode 301 action 1 actionType fallBackSrtpToRtp,fallBackToIPV4
% commit

or

When Action Type is set as fallBackSrtpToRtp and fallBackToIPV6:

% set profiles services retryProfile rp3 triggerActionRule 5 sipResponseCode 300 sipWarningCode 301 action 1 actionType fallBackSrtpToRtp,fallBackToIPV6
% commit

or

When Action Type is set as fallBackToIPV4:

% set profiles services retryProfile rp3 triggerActionRule 5 sipResponseCode 300 sipWarningCode 301 action 1 actionType fallBackToIPV4
% commit

or

When Action Type is set as fallBackToIPV6:

% set profiles services retryProfile rp3 triggerActionRule 5 sipResponseCode 300 sipWarningCode 301 action 1 actionType fallBackToIPV6
% commit

Enabling the Retry Profile and the Attempt Record Generation Option (Optional)

To enable the Retry profile and the attempt record generation option, execute the following command:

% set profiles services retryProfile rp1 attemptRecordGeneration enabled state enabled
% commit

Attaching the Retry Profile to the Trunk Group

% set addressContext default zone z1 sipTrunkGroup TG1 services retryProfile rp1
% commit

 

  • No labels