Real-time / Web

SDES (a=crypto SRTP keying)

SDES (Session Description Protocol Security DEScriptions, RFC 4568) is the legacy method for negotiating SRTP encryption keys: the master key is base64-encoded directly into the SDP body via an a=crypto attribute. Simple, broadly compatible, and dangerous when used over unencrypted SIP signaling.

How an a=crypto line is structured

a=crypto:1 AES_CM_128_HMAC_SHA1_80 \
  inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^31|1:1
       \______/  \__________/                  \__/  \_/
       tag        cipher-suite                  MKI   lifetime

       \__________________ inline params __________________/

Tag         : 1 (matches with offer/answer)
Cipher      : AES_CM_128_HMAC_SHA1_80
inline:<b64-key> = base64 of (16-byte master key + 14-byte master salt)
2^31        : key lifetime in packets
1:1         : MKI value:length (Master Key Identifier)

The offer/answer flow

Caller offers SDP with one or more a=crypto lines (typically 2-3 cipher suites).
Callee picks one cipher suite, generates its own master key, and replies with a single matching a=crypto line.
Each side now has both keys: caller key for caller→callee, callee key for callee→caller.
RTP starts encrypted immediately.

Security model: only as safe as your signaling

SDES puts the actual SRTP key in plaintext inside the SDP body. If the SIP signaling channel is unencrypted (plain UDP/TCP), anyone on the path can read the key and decrypt the call, ISPs, network operators, attackers with packet capture, etc.

Therefore SDES is only secure when the SIP signaling is itself encrypted, typically via SIP-TLS (port 5061). The combination 'SIP-TLS + SDES SRTP' is a long-standing enterprise default.

SDES vs DTLS-SRTP

	SDES	DTLS-SRTP
Key location	In SDP body (plaintext)	Derived from DTLS handshake on media port
Safe over unencrypted SIP?	No	Yes
Required by WebRTC?	No (rejected)	Yes (mandatory)
Setup latency	Zero (key is already in INVITE)	~100-300ms (DTLS handshake)
Cipher agility	Multiple offered, one picked	DTLS extension chooses
PBX compatibility	Wide (Asterisk, Cisco, Polycom, Avaya)	Modern (Asterisk pjsip 18+, FreeSWITCH 1.10+)

When SDES is still the right choice

Inside an enterprise SIP-TLS interconnect where DTLS-SRTP isn't supported on one end.
Legacy hardware phones (Polycom Soundpoint, older Cisco SCCP-converted devices).
Carrier-grade SBCs that need zero-RTT media setup (DTLS adds ~200ms).

Common bugs

One-way audio with SRTP: the offerer included a=crypto but didn't change the m-line profile from RTP/AVP to RTP/SAVP. Both must agree.
SRTP key reuse: using the same SRTP master key for multiple calls breaks the AES-CTR uniqueness guarantee. Always generate a fresh key per call.
SDES over WebRTC: WebRTC explicitly rejects SDES. Use DTLS-SRTP for any browser endpoint.