SDES-SRTP Encryption

Configure SRTP media encryption using SDP Security Descriptions (RFC 4568) with policy enforcement, cipher suite selection, and SDP profile changes.

SDES-SRTP encrypts RTP media streams by exchanging encryption keys directly in the SDP body during call setup. Defined in RFC 4568, this is the most widely supported method for SRTP key exchange in traditional SIP environments.

How It Works

The calling endpoint generates a random SRTP master key and includes it in the SDP offer as an a=crypto attribute
The answering endpoint selects a matching cipher suite from the offered options and responds with its own key in the SDP answer
Both sides derive session keys from the exchanged master keys and encrypt/decrypt RTP packets using SRTP (RFC 3711)

SDP Example

Offer:

m=audio 10000 RTP/SAVP 0
a=rtpmap:0 PCMU/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj
a=crypto:3 AEAD_AES_128_GCM inline:bQJXGzEPXJPClrd4KcE6iw==

Answer:

m=audio 20000 RTP/SAVP 0
a=rtpmap:0 PCMU/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaQ==

The answerer selected cipher suite 1 (AES_CM_128_HMAC_SHA1_80) and provided its own key. Both sides now encrypt media using their respective keys.

Cipher Suites

CallMeter supports three SRTP cipher suites:

Cipher Suite	Key Size	Auth Tag	Use Case
`AES_CM_128_HMAC_SHA1_80`	128-bit AES	80-bit HMAC-SHA1	Default. Widest compatibility, recommended for most testing.
`AES_CM_128_HMAC_SHA1_32`	128-bit AES	32-bit HMAC-SHA1	Reduced overhead. Lower authentication strength, suitable for bandwidth-constrained tests.
`AEAD_AES_128_GCM`	128-bit AES	GCM integrated	Modern authenticated encryption. Best security, but requires endpoint support.

When multiple suites are offered, the answering endpoint selects the one it supports and prefers. The offer order does not mandate priority — the answerer chooses.

Policy Enforcement

SRTP policy controls how the endpoint handles encryption negotiation:

Policy	Behavior
Disabled	No `a=crypto` lines in SDP. Media uses unencrypted RTP.
Offered	`a=crypto` lines included in SDP, but unencrypted fallback is allowed if the remote does not support SRTP.
Required	`a=crypto` lines included in SDP. If the remote does not respond with a matching `a=crypto`, the call is rejected.

Required policy and legacy systems

Setting the SRTP policy to Required will cause calls to fail against endpoints that do not support SRTP. Use Offered when testing mixed environments with both encrypted and unencrypted endpoints.

RTP Profile Change

When SDES-SRTP is negotiated, the RTP profile in the SDP m= line changes:

Without SRTP	With SRTP
`RTP/AVP`	`RTP/SAVP`
`RTP/AVPF`	`RTP/SAVPF`

The "S" in SAVP/SAVPF indicates Secure Audio-Visual Profile. This tells both endpoints that SRTP encryption is in effect for that media line.

Security Considerations

SDES exchanges encryption keys in plaintext within the SDP body. Any entity that can read the SDP — SIP proxies, session border controllers, call recording systems — can also read the SRTP keys and decrypt the media.

For environments where key confidentiality is critical, use DTLS-SRTP instead. DTLS performs the key exchange over a separate encrypted handshake on the media path, so keys are never exposed in signaling.

When to Use SDES-SRTP

SIP trunk providers that require SRTP but do not support DTLS
Enterprise PBX systems (Cisco CUCM, Avaya, etc.) that use SDES as their primary encryption method
Session border controllers that need to inspect and re-encrypt media (lawful intercept, call recording)
Compliance testing where any encryption is required but DTLS is not available

Next Steps

DTLS-SRTP — Handshake-based key exchange for stronger key confidentiality
TLS Certificates — Encrypt the SIP signaling channel
SRTP Methods Reference — Detailed bitmask and profile mapping

SDES-SRTP Encryption

On this page