How SRTP Works: Encrypting the Actual Phone Call

RTP, the protocol that carries VoIP audio, is plaintext. Every packet contains a chunk of encoded audio, and anyone who can see those packets on the network can decode them into a listenable conversation. This isn't a theoretical risk. Tools like Wireshark can reconstruct a phone call from a packet capture in a few clicks. Any router, switch, or tap point between the two endpoints has access to the full conversation.

SRTP exists to fix this. It's defined in RFC 3711 and it does exactly what you'd expect: encrypts the audio payload of each RTP packet so that intercepting the packets gives you nothing useful.

But SRTP itself only handles the encryption and authentication of media packets. It doesn't solve the harder problem: how do both sides agree on the encryption keys in the first place? That key exchange problem is where the real complexity lives, and it's where most of the interoperability headaches come from.

What SRTP adds to RTP

SRTP wraps around RTP without changing the fundamental packet structure. The RTP header stays in the clear (sequence numbers, timestamps, SSRC identifiers are still readable), but the payload, the actual audio data, gets encrypted. SRTP also appends an authentication tag to each packet.

This gives you three things that plain RTP doesn't have:

Confidentiality. The audio payload is encrypted with AES, typically AES-128 in counter mode. Anyone intercepting the packet gets the RTP headers (which tell you that a call is happening and how many packets are flowing) but not the audio content.

Authentication. The HMAC-SHA1 authentication tag covers both the header and the encrypted payload. If anyone modifies the packet in transit, the receiving side detects it and discards the packet. This prevents an attacker from injecting audio or modifying the stream.

Replay protection. SRTP maintains a replay list based on packet sequence numbers. If an attacker captures a packet and retransmits it later, the receiving side recognizes it as a duplicate and drops it.

The encryption uses a master key and a master salt to derive separate session keys for encryption and authentication. The key derivation function means that even if an attacker compromises one session key, they can't easily work backward to the master key or forward to future session keys.

The key exchange problem

SRTP defines how to encrypt packets once both sides have a shared key. It says nothing about how both sides get that key. This is a deliberate design choice: it separates the media protection mechanism from the key management mechanism, allowing different key exchange approaches for different use cases.

Three approaches have emerged, each with different security properties and different deployment contexts.

SDES: keys in the signaling

SDES (Session Description Protocol Security Descriptions, RFC 4568) is the simplest approach. The encryption key is carried directly in the SDP that's exchanged during call setup. When an endpoint sends an INVITE with an SDP offer, it includes a crypto attribute containing the SRTP master key, encoded in base64:

m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
  inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnsKMjI=

The RTP/SAVP profile in the media line indicates SRTP (as opposed to RTP/AVP for plain RTP). The a=crypto line specifies the cipher suite and the key material. The answering side picks a crypto suite from the offer and includes its own key in the SDP answer.

The security model here is straightforward: if the SIP signaling is protected, the keys are protected. If the signaling is not protected, anyone who can see the SIP messages can extract the SRTP keys and decrypt the media.

This is why SDES only makes sense when the signaling runs over TLS (or more precisely, when every hop in the signaling path uses TLS). If your SIP INVITE travels over UDP in plaintext, the SRTP keys are right there in the SDP body for anyone to read. You'd have encrypted media with the keys published in the clear: security theater.

In practice, most business VoIP deployments use SDES. The SIP trunk from your PBX to your provider runs over TLS, the keys are exchanged in the encrypted signaling, and the media is encrypted with SRTP. It works, it's simple, and it's well supported. The trust model is that you trust each SIP proxy in the signaling path not to misuse the keys, which is a reasonable assumption when the signaling path is your PBX talking directly to your provider's SBC.

The weakness shows up when the signaling traverses multiple hops through proxies you don't control. Each proxy that handles the SIP messages has access to the SRTP keys. SDES provides encryption against passive eavesdropping on the media path, but it doesn't provide end-to-end encryption if the signaling intermediaries are untrusted.

DTLS-SRTP: keys on the media path

DTLS-SRTP (RFC 5763/5764) takes a fundamentally different approach. Instead of carrying keys in the signaling, the two endpoints perform a DTLS handshake directly on the media path: the same UDP ports that will carry the RTP packets. DTLS is essentially TLS adapted for UDP (since the media path uses UDP, not TCP).

The handshake uses Diffie-Hellman key exchange to establish a shared secret, from which the SRTP master key is derived. The signaling (SDP) carries only a fingerprint of each endpoint's DTLS certificate, not the key material itself:

m=audio 49170 UDP/TLS/RTP/SAVPF 111
a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B...
a=setup:actpass

This is a stronger security model than SDES because the key material itself never traverses the signaling path: passive interception of the SIP messages yields no keys. But it's not independent of the signaling. The certificate fingerprints in the SDP are what bind the DTLS handshake to the endpoints the signaling identified, and RFC 5763 requires that binding to be protected: the fingerprint must travel over authenticated signaling (SIP over TLS end to end, or another identity mechanism). An active attacker who can rewrite the SDP can substitute their own fingerprint and man-in-the-middle the handshake. When the fingerprint arrives intact, a mismatch between it and the certificate presented in the handshake tells the endpoint something is wrong, and the connection is refused.

Browser-based calling mandates DTLS-SRTP. There is no option to use unencrypted media in a browser call: every browser media connection goes through a DTLS handshake before any audio or video flows. This is one of the design decisions that makes browser calling fundamentally more secure than traditional SIP for media encryption. The browser enforces it; the application can't opt out.

The tradeoff is complexity. The DTLS handshake adds a round trip before media can flow, and both endpoints need to support the DTLS stack. In the browser this is built in, so developers don't think about it. For traditional SIP endpoints, DTLS-SRTP support is less universal than SDES support.

ZRTP: Zimmermann's approach

ZRTP (RFC 6189) was designed by Phil Zimmermann (of PGP fame) and takes yet another approach to the key exchange problem. Like DTLS-SRTP, it performs key exchange on the media path itself using a Diffie-Hellman exchange. Its distinctive property is that man-in-the-middle detection doesn't rely on the SIP signaling at all: the Short Authentication String (SAS) gives the humans on the call a way to verify the exchange themselves. (DTLS-SRTP also detects a MITM when its fingerprint is properly authenticated; ZRTP's difference is that its check is independent of signaling integrity.)

During the ZRTP handshake, both endpoints compute a short string (typically four characters or two words) derived from the key exchange. The users are supposed to read this string to each other over the voice channel and verify that they match. If an attacker is performing a man-in-the-middle attack, they'd have separate key exchanges with each endpoint, and the SAS values would differ.

ZRTP also implements key continuity: it caches key material from previous calls between the same endpoints, so that subsequent calls can detect if the key exchange parameters change unexpectedly (which might indicate a new man-in-the-middle attack).

In practice, ZRTP is niche. The SAS verification step requires user participation, which makes it impractical for most business VoIP deployments. You're not going to ask call center agents to verify authentication strings on every call. ZRTP found a home in privacy-focused applications (Signal's voice calling was influenced by ZRTP's design principles), but it never achieved mainstream adoption in enterprise VoIP.

Which approach is used where

The landscape is fairly predictable:

Traditional business VoIP (SIP trunking, hosted PBX): SDES with TLS on the signaling path. This is the default for most SIP trunk providers and most IP PBXes. It's well understood, widely supported, and provides adequate security when the signaling path is encrypted.

Browser-based calling (softphones in a tab, UCaaS platforms): DTLS-SRTP, mandatory. No negotiation, no fallback to unencrypted. This applies to any platform that runs its media path through the browser, including many modern UCaaS products.

Privacy-focused applications: ZRTP or ZRTP-inspired designs. Rare in enterprise deployments.

Legacy or budget VoIP: Plain RTP with no encryption at all. More common than it should be. We'll come back to this.

Performance overhead

A persistent myth in VoIP operations is that SRTP adds meaningful overhead, enough to justify not enabling it. This is wrong.

AES-128 encryption of a single RTP packet takes microseconds on any hardware built in the last fifteen years. Modern CPUs have AES-NI instructions that make the encryption essentially free in terms of processing time. The HMAC-SHA1 authentication tag computation is similarly fast.

The per-packet overhead in terms of bytes is the authentication tag (typically 10 bytes with the 80-bit tag, or 4 bytes with the 32-bit tag) and potentially a few bytes for the MKI (Master Key Identifier) if key rotation is in use. On a G.711 packet carrying 160 bytes of audio, 10 extra bytes is a 6% increase in payload size. On an Opus packet the fixed tag is proportionally larger: Opus payloads (RFC 7587) are often a few dozen bytes at typical voice bitrates, so 10 bytes can be 20% or more of the payload. But in absolute terms it's still 10 bytes per packet, which is negligible against the link's total budget.

The DTLS handshake does add latency at call setup: one or two round trips before media can flow. In practice this adds tens of milliseconds to the time before first audio, which is not perceptible to users given that SIP call setup already involves multiple round trips of signaling.

There is no legitimate performance reason to skip SRTP in any modern deployment.

Common problems caused by encryption mismatches

Encryption mismatches cause some of the most confusing troubleshooting scenarios in VoIP, particularly one-way audio and no-audio conditions.

One side expects SRTP, the other doesn't. If one endpoint sends encrypted media and the other is expecting plain RTP, the receiving side gets packets it can't decode. The audio codec sees garbled input and either outputs silence or noise. The call appears to connect normally at the SIP level (the INVITE succeeds, a 200 OK comes back, media flows in both directions), but one or both sides can't hear anything. In a SIP trace, the clue is in the SDP: look for RTP/SAVP on one side and RTP/AVP on the other, or look for the presence of a=crypto lines on one side and their absence on the other.

Mismatched cipher suites. Both sides want SRTP but they don't support a common cipher suite. Most implementations support AES_CM_128_HMAC_SHA1_80, which is the mandatory-to-implement suite from RFC 3711, so this is rare. But it does happen with older or non-standard implementations.

SRTP-to-SRTP through a non-SRTP intermediary. An SBC or media proxy in the middle that doesn't support SRTP will strip the crypto attributes from the SDP or fail the call entirely. This shows up when migrating to encrypted trunks: the PBX and provider both support SRTP, but a middle box that nobody remembered about doesn't.

Certificate fingerprint mismatches with DTLS-SRTP. In browser-calling deployments, if the DTLS certificate fingerprint in the SDP doesn't match the certificate presented during the DTLS handshake, the handshake fails and no media flows. A TURN server is not the usual culprit: TURN (RFC 8656) relays the DTLS packets unchanged, so the endpoint certificates pass through intact. A mismatch points instead at something that terminates or rewrites the media or signaling: an SBC or media gateway re-originating DTLS with its own certificate without updating the SDP fingerprint, or signaling elements mangling the fingerprint attribute.

All of these problems share a characteristic: the SIP signaling looks normal. The call connects. The issue is entirely in the media plane, and you need to look at the SDP details and the actual media packets to diagnose it.

Why some providers still don't encrypt media

Despite SRTP being well established and having negligible performance cost, there are still VoIP providers and enterprise deployments running plain RTP. The reasons are mostly inertial rather than technical.

Legacy equipment. Older SIP endpoints, gateways, and PBXes that predate widespread SRTP support are still in production. Upgrading firmware or replacing hardware costs money, and if the system works, there's organizational resistance to changing it.

Interoperability caution. Providers who serve a wide range of customers with diverse equipment may default to plain RTP because it's the lowest common denominator. Enabling SRTP by default risks breaking calls for customers whose equipment doesn't support it.

"It's on our private network." Some organizations argue that media encryption is unnecessary because the RTP traffic stays on their private LAN or a dedicated MPLS circuit. This ignores the reality that private networks get compromised, internal actors exist, and the perimeter between "private" and "public" is increasingly blurry.

This is changing. Regulatory pressure (particularly in healthcare and finance), the growth of remote work (where "private network" no longer describes the path between a softphone on a home network and the corporate PBX), and the general shift toward encrypting everything by default are all pushing the industry toward mandatory SRTP. The browser platform's decision to make encryption non-optional has normalized the expectation that voice traffic should be encrypted.

If you're evaluating a VoIP provider and they don't support SRTP, that's a red flag, not just for security, but as an indicator of how current their infrastructure is.

For more on how SIP authentication and signaling security work (including TLS for the signaling path that SDES depends on), how SDP negotiation handles the crypto attributes described in this post, and how to read a SIP trace to spot encryption mismatches, see those posts. If you're troubleshooting a call that connects but has no audio, the one-way audio guide covers the full range of causes, including encryption mismatches.