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
supports Secure RTP and its associated secure real-time transport control protocol (Secure RTCP) for IPv4/IPv6 addressing for both audio and video streams.
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
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
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
.
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
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
negotiates the use of Secure RTP/RTCP with its peer. If the
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.
The
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 . For example, Direct Media with TLS/SRTP is applicable for a distributed network containing two s.
The
platforms support the following crypto suites for SRTP and SRTCP encryption:
Div |
---|
|
Caption |
---|
0 | Table |
---|
1 | SRTP and SRTCP Crypto Suites |
---|
3 | SRTP and SRTCP Crypto Suites |
---|
|
Crypto Suite | Master Key Length (bits) | Salt Value (bits) | Cipher | Key Derivation Function | Encryption key (bits) | Message Authentication Code | Authentication tag length (bits) | Authentication key length (bits) |
---|
AEAD-AES-128- GCM | 128 | 96 | AES-CM | AES_CM PRF [RFC3711] | 128 | Galois Message Authentication Code (GMAC) | 128 | N/A | AEAD-AES-256- GCM | 256 | 96 | AES-CM | AES_256_CM_PRF [RFC6188] | 256 | Galois Message Authentication Code (GMAC) | 128 | N/A | AES-CM-128- HMAC- SHA1-32 | 128 | 112 | AES Counter Mode | AES_128_CM_PRF | 128 | HMAC-SHA1 | 32 | 160 | AES-CM-128- HMAC-SHA1-80
| 128 | 112 | AES Counter Mode | AES_128_CM_PRF | 128 | HMAC-SHA1 | 80 | 160 | AES-CM-192- HMAC-SHA1-32 | 192 | 112 | AES Segmented Integer Counter Mode | AES_192_CM_PRF | 192 | HMAC_SHA1 | 32 | 160 | AES-CM-192- HMAC-SHA1-80 | 192 | 112 | AES Segmented Integer Counter Mode | AES_192_CM_PRF | 192 | HMAC_SHA1 | 80 | 160 | AES-CM-256- HMAC-SHA1-32 | 256 | 112 | AES Segmented Integer Counter Mode | AES_256_CM_PRF | 256 | HMAC_SHA1 | 32 | 160 | AES-CM-256- HMAC-SHA1-80 | 256 | 112 | AES Segmented Integer Counter Mode | AES_256_CM_PRF | 256 | HMAC_SHA1 | 80 | 160 |
|
|
Multiexcerpt |
---|
MultiExcerptName | SRTP_RTP_Fallback_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. Info |
---|
| - 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.
|
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.
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.
The functionality of the retryProfile is explained as follows:
|
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: Code Block |
---|
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: Code Block |
---|
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.
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. Caption |
---|
0 | Figure |
---|
1 | Call Flow - Scenario 1 |
---|
| Image Modified |
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. Caption |
---|
0 | Figure |
---|
1 | Call Flow - Scenario 2 |
---|
| Image Modified |
|