Configuring SRTP to RTP Fallback

In this section:

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.

Figure 1: 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.

Figure 2: Call Flow - Scenario 2

SSRC Randomization for SRTP Calls

The synchronization source (SSRC) identifier uniquely identifies media streams within an RTP session when establishing or modifying media sessions. In its standard processing, the SBC generates an SSRC when it transcodes a media stream and relays the SSRCs in pass-through calls. To provide flexibility in managing SSRC values in SRTP media flows, the SBC provides a configuration option (ssrcRandomizeForSrtp) to direct the SBC to generate and replace (randomize) the SSRC in both pass-through and transcoded SRTP media flows. When you enable the ssrcRandomizeForSrtp option, the SBC:

generates and replaces the SSRC for both pass-through and transcoded SRTP media flows
generates a new SSRC value when a mid-call modification occurs (such as hold/resume)
replaces the CNAME in the SRTCP SDES block
replaces the SSRC in the SRTCP report blocks

The option for randomizing the SSRC for SRTP occurs as a flag within the Packet Service Profile (PSP). Through the PSP you assign to the ingress and egress trunk group for a call, you can control whether to enable the option on the ingress leg, egress leg, or both legs of a call flow. If the option is disabled on either call leg, the SBC relays the SSRC for pass-through media flows it receives from the peer on that leg.

Note that the existing PSP flag ssrcRandomize applies only to controlling whether to generate a new SSRC when a mid-call modification occurs in a transcoded session, and not to pass-through calls.