Page History
Add_workflow_for_techpubs | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Panel | |
---|---|
In this section:
|
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
Spacevars | ||
---|---|---|
|
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
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
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
Spacevars | ||
---|---|---|
|
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
Spacevars | ||
---|---|---|
|
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
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Direct Media Using SIP-TLS SRTP
The
Spacevars | ||
---|---|---|
|
- 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 twoSpacevars 0 product
s.Spacevars 0 product
SRTP Crypto Suites
The
Spacevars | ||
---|---|---|
|
SRTP and SRTCP Crypto Suites
Crypto | Master Key | Salt | Cipher | Key | Encryption | Message | Authentication | Authentication |
---|---|---|---|---|---|---|---|---|
AEAD-AES-128- | 128 | 96 | AES-CM | AES_CM PRF | 128 | Galois Message | 128 | N/A |
AEAD-AES-256- | 256 | 96 | AES-CM | AES_256_CM_PRF | 256 | Galois Message | 128 | N/A |
AES-CM-128- HMAC- SHA1-32 | 128 | 112 | AES | AES_128_CM_PRF | 128 | HMAC-SHA1 | 32 | 160 |
AES-CM-128- | 128 | 112 | AES | AES_128_CM_PRF | 128 | HMAC-SHA1 | 80 | 160 |
AES-CM-192- | 192 | 112 | AES Segmented | AES_192_CM_PRF | 192 | HMAC_SHA1 | 32 | 160 |
AES-CM-192- | 192 | 112 | AES Segmented | AES_192_CM_PRF | 192 | HMAC_SHA1 | 80 | 160 |
AES-CM-256- | 256 | 112 | AES Segmented | AES_256_CM_PRF | 256 | HMAC_SHA1 | 32 | 160 |
AES-CM-256- | 256 | 112 | AES Segmented | AES_256_CM_PRF | 256 | HMAC_SHA1 | 80 | 160 |
SRTP to RTP Fallback on Receipt of 488
Multiexcerpt | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||
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 SupportFor 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:
IPV4/IPV6 Inter-working SupportWhen the SBC receives an error response, which is configured on the profile and the corresponding action is configured as fallback:
Retry Profile The functionality of the
Call FlowsScenario 1When SRTP is configured and the SBC receives an error response for an SRTP offer, it checks the response code against the Call Flow - Scenario 1 Scenario 2When SRTP is configured and the SBC receives an error response for an SRTP offer, it checks the response code against the If the response code is configured on the
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 CallsThe 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 (
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 |