In this section:
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.
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:
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.
The SBC supports the following Direct Media functionality:
The SBC Core platforms support the following crypto suites for SRTP and SRTCP encryption:
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 |
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. 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: When the SBC receives an error response, which is configured on the profile and the corresponding action is configured as fallback: The functionality of the 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. 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. Example: 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. 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 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 Call Flow - Scenario 1 When 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 2retryProfile
is configured, it takes precedence over cranback/redirection/maddr handling functionality.retryProfile
is not associated with the IPTG, the SBC functions with the existing behavior.SRTP to RTP Fallback Support
IPV4/IPV6 Inter-working Support
Retry Profile
retryProfile
is explained as follows:
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
}
}
The execution is stopped when:
triggerActionRule Rule 1
{
Response Code: 488
Warning Code: 301
Action Set1:
{
Fallback from SRTP to RTP
}
Action Set2:
{
Fallback to IPv6
}
}
Example:
triggerActionRule Rule1
{
Response Code: 488
Warning Code: 301
Action Set1:
{
Fallback from SRTP to RTP
Fallback to IPv4
}
}
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
}
}
Call Flows
Scenario 1
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.Scenario 2
retryProfile
linked to the IPTG.retryProfile
with the following actions: