What Is SRTP and How Does It Protect Voice Traffic?

SRTP, the Secure Real-time Transport Protocol, is a security profile for RTP that encrypts the audio payload of each packet and adds an authentication tag so the packet cannot be altered or replayed without detection. It is defined in RFC 3711. In a SIP call, SRTP protects the voice itself, while TLS protects the SIP signalling. The two are complementary. SRTP without TLS is weak because the keys usually travel inside the signalling, and TLS without SRTP leaves the audio readable to anyone who can capture the RTP packets.

Why is plain RTP a problem?

RTP, defined in RFC 3550, carries audio as a sequence of small UDP packets. Each packet has a 12-byte header and a payload holding 20 milliseconds or so of encoded speech. Nothing in RTP is encrypted. Anyone with access to the network path can capture the packets, reassemble the stream and play back the conversation. Packet analysers do this with a couple of clicks. The risk is highest on shared Wi-Fi, in hotels and on any path across the public internet. SRTP exists to close this gap.

How does SRTP protect each packet?

SRTP takes an ordinary RTP packet and applies two operations.

1. Encryption. The payload is encrypted with a symmetric cipher. The default is AES in counter mode with a 128-bit key. The RTP header stays in clear text so that routers, mixers and the receiving jitter buffer can still read the sequence number, timestamp and SSRC. Only the audio is hidden.
2. Authentication. An HMAC-SHA1 tag, normally truncated to 80 bits (10 bytes), is appended to the packet. It covers the header and the encrypted payload. The receiver recomputes the tag and discards any packet that does not match. This prevents an attacker from injecting or modifying audio.

SRTP also keeps a replay list so that a captured packet cannot be sent again later. The companion protocol SRTCP applies the same protection to RTCP reports.

The cost is small. The payload is the same size as before, and the tag adds 10 bytes to a packet that is already about 200 bytes for G.711 at 20 milliseconds, or roughly 80 to 140 bytes for Opus at typical voice bitrates. The encryption itself is cheap on any modern CPU.

Where do the SRTP keys come from?

SRTP defines how to use keys but not how to agree on them. Two methods are common in SIP.

SDES: keys in the SDP

SDP Security Descriptions, defined in RFC 4568, put the key material directly in the SDP body of the INVITE and 200 OK. Each side includes one or more a=crypto lines naming a cipher suite and a base64-encoded master key and salt. The media line uses the profile RTP/SAVP instead of RTP/AVP. Clients that treat SRTP as optional often keep RTP/AVP and add the crypto lines anyway, so that a server without SRTP can still accept the call. That is a common convention rather than part of RFC 4568.

m=audio 10000 RTP/SAVP 111 0 8
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:XBJ4aAsroBt1VG1+wj0KSXWeXBIoXC5HrQxfPqLZ

SDES is simple and widely supported by PBXs such as Asterisk and by many softphones. Its weakness is obvious: the key is in the signalling. If the SIP messages travel over UDP or TCP, the key is visible, and anyone who captured the INVITE can decrypt the call. SDES therefore only makes sense together with TLS signalling.

DTLS-SRTP: keys from a handshake on the media path

DTLS-SRTP, defined in RFC 5764 and applied to SIP by RFC 5763, runs a Datagram TLS handshake directly between the two media endpoints on the RTP port and derives the SRTP keys from it. The SDP carries only a certificate fingerprint in an a=fingerprint line, and the media profile is UDP/TLS/RTP/SAVP. The keys never appear in the signalling. This is the method WebRTC uses. Among SIP softphones and PBXs it is less universal than SDES, so check support on both ends before relying on it.

How is SRTP negotiated in a call?

The offer/answer model handles it. The caller lists what it supports in the INVITE. The callee picks. Three outcomes are possible.

• Both offer and accept SRTP. The call is encrypted.
• The caller offers SRTP and the callee only supports plain RTP. Depending on the caller's policy, either the call falls back to plain RTP or it fails.
• The caller offers plain RTP only. The call is unencrypted even if the callee could have done SRTP.

Softphones expose this as a policy. SIPdia, for example, has an Encrypt audio setting with three values: Off, Optional and Required. Off never offers SRTP. Optional offers it and accepts a fallback to plain RTP. Required insists on SRTP and the call fails if the other side cannot provide it. Other clients use similar terms such as "preferred" and "mandatory".

Note that when a PBX sits in the media path, the encrypted leg runs between the client and the server. A PBX in that position decrypts the audio, processes it for recording or bridging, and re-encrypts or sends it onward in the clear depending on the next hop's capabilities. SRTP from your softphone protects your leg of the call, not the whole path.

What settings does the server need?

On Asterisk-based systems, SRTP support is per endpoint. In the PJSIP configuration the media_encryption option takes the values no, sdes or dtls, and media_encryption_optimistic=yes allows fallback to plain RTP when the far end does not support it. The PBX must have the SRTP library installed, and for TLS signalling it needs a certificate. FreePBX and Issabel expose these options in the extension settings; consult their documentation for the exact labels in your version.

How does SRTP relate to TLS?

Layer	Protocol	What it protects
Signalling	TLS on port 5061	SIP headers, SDP, authentication exchange, SRTP keys
Media	SRTP on negotiated RTP ports	Audio payload, integrity of each packet

Use both for a private call. Using TLS alone hides who you are calling but leaves the audio readable. Using SRTP alone with SDES exposes the key. SIP over UDP, TCP and TLS explains the signalling side in detail.

What SRTP does not do

• It does not hide the fact that a call is taking place, or its duration. The RTP headers and the packet timing remain visible.
• It does not protect against a compromised server, since the server holds the keys for its leg.
• It does not authenticate the person on the other end. It authenticates packets, not people.
• It does not replace network security. A PBX exposed to the internet still needs firewalling, rate limiting and strong passwords.

Next steps

See how SRTP policy appears in practice on the TLS and SRTP feature page and the broader security page. For the protocol that SRTP protects, read Understanding RTP and audio streams.