SRTP for Media

Overview

The Secure Real-time Transport Protocol (Secure RTP or SRTP) is an IETF cryptographic protocol used to provide secure communications over untrusted networks as described in RFC 3711. SRTP provides confidentiality, message authentication and replay protection to Internet media traffic such as audio and video. The SBC Core supports Secure RTP and its associated secure real-time transport control protocol (Secure RTCP) for IPv4/IPv6 addressing for both audio and video streams.

SRTP Functionality

Secure RTP on the SBC is available using SIP signaling over UDP, TCP, and TLS (Transport Layer Security) protocol, and is signaled by specifying Secure RTP transport in an SDP (Session Description Protocol) media (m=) line. The SBC Core uses the RFC 4568 Security Descriptions ("sdescriptions") standard for negotiating the use of Secure RTP. TLS over TCP is recommended for SIP transport when negotiating Secure RTP, because it protects the integrity and confidentiality of the sRTP keys which would otherwise be exposed. The SBC supports sRTP on all call legs.

The use of Secure RTP on one call leg is independent of its use on other legs of the same call, and is negotiated for each packet leg. Secure RTP may be used outside or inside the network. All Secure RTP calls are routed through the SBC. 

Use of Secure RTP is provisioned on a Packet Service Profile basis; separate packet service profiles may be applied to Ingress and Egress packet signaling. 

The  SBC supports the crypto-suite "aes-cm-128-hmac-sha1-80" and "aes-cm-128-hmac-sha1-32" for Secure RTP. Secure RTP is requested by the presence of RTP/SAVP or RTP/SAVPF in the m= line.

The appropriate crypto suite profile may also include valid combinations of the following session parameters:

• UNENCRYPTED_SRTP—SRTP packet payloads are not encrypted.
• UNENCRYPTED_SRTCP—SRTCP packet payloads are not encrypted.
• UNAUTHENTICATED_SRTP—SRTP packet payloads are not authenticated.

By default, SRTP and SRTCP packet payloads are both authenticated and encrypted. The SRTP specification requires message authentication for SRTCP, but not for sRTP (RFC3711). Use of UNAUTHENTICATED_SRTP is not recommended.

The SBC negotiates the use of Secure RTP/RTCP with its peer. If the SBC and its peer cannot agree on the RTP/RTCP parameters for the connection, they can either terminate the call or continue the call with no security based on the provisioning of a fallback parameter.

Direct Media Using SIP-TLS SRTP

The SBC supports the following Direct Media functionality:

• Direct Media over SRTP/TLS between subscribers in the same Media Group for both audio and video calls.
• Direct Media between endpoints in the same media zone belonging to the same or different SBC. For example, Direct Media with TLS/SRTP is applicable for a distributed network containing two SBCs.

SRTP Crypto Suites

The SBC Core platforms support the following crypto suites for SRTP and SRTCP encryption:

SRTP and SRTCP Crypto Suites

SRTP to RTP Fallback on Receipt of 488

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.

SRTP to RTP Fallback Support

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

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.