Real-time / Web

SRTP (Secure RTP)

SRTP (RFC 3711) is the encrypted version of RTP. It uses AES-CTR for confidentiality and HMAC-SHA1 for authentication, applied to the RTP payload. Without SRTP, anyone on the network path can record your call audio in plaintext.

What SRTP encrypts

• Encrypted: the RTP payload (the actual audio/video bits).
• Authenticated, not encrypted: the RTP header (sequence number, timestamp, SSRC). Authentication prevents tampering and replay.
• Not protected: packet timing, packet sizes — an observer can still see that a call is happening, just not what is being said.

SRTP needs a key — how does it get one?

This is the most-confused part of SRTP. SRTP itself does not negotiate keys. The keys come from a separate keying mechanism. There are three real options:

Method	Where keys come from	Used by	Safe over plain SIP?
SDES (RFC 4568)	SDP a=crypto attribute	Older SIP phones, Cisco	No — key is plaintext in SDP
DTLS-SRTP (RFC 5763)	DTLS handshake on the media port	WebRTC, modern PBXs	Yes — keys never in SIP signaling
MIKEY (RFC 3830)	Inside SDP, public-key cryptography	Niche enterprise	Mostly

SDES: the historic default

SDES (Session Description protocol Security DEScriptions) puts the SRTP master key directly in the SDP body of the SIP INVITE.

# In the SDP m=audio block:
m=audio 16384 RTP/SAVP 0 8 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 \
  inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^31

The key is base64-encoded after inline:. If the SIP signaling is unencrypted (plain UDP/TCP), anyone on the path reads the key — SDES is only safe when wrapped in SIP-TLS. Don't ship SDES on plain SIP.

DTLS-SRTP: how WebRTC does it

DTLS-SRTP keeps the SRTP keys out of SDP entirely. SDP only carries a fingerprint of each side's DTLS cert; the real keys are derived from a DTLS handshake performed on the media port.

# SDP advertises a fingerprint, not a key
m=audio 16384 UDP/TLS/RTP/SAVP 111 0 8
a=fingerprint:sha-256 75:74:5A:A6:A4:E5:52:F4:A7:67:4C:01:39:A1:36:4D:...
a=setup:actpass

# Then over UDP port 16384, a DTLS handshake runs.
# The DTLS export-key extension yields SRTP master keys.

This is why DTLS-SRTP is safe even over plain UDP SIP signaling: the SRTP keys never appear in the SIP messages at all. See DTLS-SRTP detail page.

Profile names you'll see in SDP

SDP profile	Means
RTP/AVP	Plain RTP, no encryption
RTP/SAVP	SRTP keyed via SDES
RTP/SAVPF	SRTP + RTCP feedback (WebRTC)
UDP/TLS/RTP/SAVP	SRTP keyed via DTLS-SRTP
UDP/TLS/RTP/SAVPF	SRTP + DTLS keying + RTCP feedback (WebRTC)

Cipher suites

• AES_CM_128_HMAC_SHA1_80 — baseline, ~80-bit auth tag. Universal.
• AES_CM_128_HMAC_SHA1_32 — shorter auth tag for low-bandwidth links.
• AEAD_AES_128_GCM / AEAD_AES_256_GCM — modern AEAD, RFC 7714. Preferred for new deployments.

DIDHub SRTP support

DIDHub trunks accept all three keying methods. WebRTC clients use DTLS-SRTP. PBX trunks over SIP-TLS commonly use SDES (with TLS protecting the key in transit). Plain RTP is accepted on private-network interconnects only.

Related terms