DTLS in VoIP: How DTLS and DTLS-SRTP Secure WebRTC and SIP Media Keys

Every encrypted voice call has a chicken-and-egg problem: the audio is protected by SRTP, but SRTP needs a secret key, and that key has to reach both endpoints without an eavesdropper intercepting it first. How the two sides agree on that key is the single most important decision in real-time media security, and it is where DTLS earns its place in the stack.

Datagram Transport Layer Security (DTLS) brings the confidentiality and authentication of TLS to unreliable, packet-loss-tolerant transports like UDP, which is exactly what real-time voice and video run on. Paired with SRTP, it becomes DTLS-SRTP: the key-exchange mechanism that WebRTC makes mandatory and that increasingly appears at the boundary between browser-based media and traditional SIP networks. This guide covers what DTLS is, how the DTLS handshake works over UDP, how DTLS-SRTP negotiates media keys, how DTLS differs from TLS, and where a Session Border Controller sits in the middle of it all.

What Is DTLS?

DTLS is TLS re-engineered for transports that do not guarantee delivery or ordering. Standard TLS assumes a reliable, in-order byte stream, which is what TCP provides. Real-time media does not run on TCP, because a retransmitted voice packet that arrives late is worse than useless: the moment it represents has already passed. Voice and video run on UDP, where packets can be lost, duplicated, or reordered, and TLS as written cannot cope with that.

DTLS solves the problem by keeping the TLS security model intact while adding the machinery UDP lacks. It introduces explicit sequence numbers so a receiver can detect gaps and reordering, a retransmission timer so a lost handshake message is resent rather than stalling the connection, and a rule that each handshake message fits within transport limits. The cryptography, the cipher suites, and the trust model are the same ones TLS uses. What changes is the packaging around them.

The protocol has evolved alongside TLS. DTLS 1.2 (RFC 6347) maps to TLS 1.2, and DTLS 1.3 (RFC 9147) maps to TLS 1.3, inheriting its faster handshake and modern cipher suites. In VoIP, DTLS matters for one dominant reason: it is the mechanism WebRTC uses to establish the keys that protect media.

How the DTLS Handshake Works

The DTLS handshake follows the same logical shape as a TLS handshake, with adaptations that let it complete reliably over a lossy datagram channel. The goal is unchanged: two endpoints authenticate each other and agree on a shared secret before any protected media flows.

The Handshake Flow

1. ClientHello and HelloVerifyRequestThe client opens with a ClientHello. The server replies with a HelloVerifyRequest carrying a stateless cookie, and the client resends its ClientHello with that cookie echoed back. This round trip exists to blunt denial-of-service amplification: the server commits no state until it has proof the client can receive at the address it claims.
2. Server parameters and certificateThe server sends its ServerHello with the chosen cipher suite, followed by its certificate and key-exchange parameters. In DTLS-SRTP the certificate is typically self-signed, because trust comes from a fingerprint carried in signaling rather than a public CA.
3. Client key exchange and certificateThe client sends its own key-exchange contribution and, when mutual authentication is in play, its own certificate. Both sides now hold the material to derive a shared master secret.
4. ChangeCipherSpec and FinishedEach side signals that it will switch to the negotiated keys, then sends a Finished message covering a hash of the entire handshake. If either Finished fails to verify, the handshake is torn down.

Throughout, every flight of messages is protected by a retransmission timer. If an expected reply does not arrive, the sender resends rather than assuming failure, which is what allows the handshake to complete over a path that quietly drops packets.

Why the Cookie Exchange Matters

The HelloVerifyRequest cookie is a small detail with an outsized security role. Because DTLS runs on UDP, an attacker can trivially forge the source address of a ClientHello and point the server’s expensive cryptographic response at a victim. Requiring the client to echo a server-issued cookie forces it to prove it can actually receive traffic at its stated address, shutting down that amplification vector before any real work begins.

How DTLS-SRTP Negotiates Media Keys

DTLS-SRTP is not a way to encrypt media. The media is still carried by SRTP, exactly as it would be with any other key-exchange method. What DTLS-SRTP does is solve the harder problem of getting the SRTP keys to both endpoints securely. It does this by running a full DTLS handshake directly on the media path, then deriving the SRTP keys from the secret that handshake produces.

The elegant part is how trust is anchored. The two endpoints exchange self-signed certificates during the DTLS handshake, but a self-signed certificate proves nothing on its own. The binding comes from signaling: each endpoint publishes a hash of its certificate as an a=fingerprint attribute in the SDP of the SIP or WebRTC offer and answer. When the DTLS handshake completes, each side compares the certificate it actually received against the fingerprint it was promised in signaling. A match confirms it handshook with the intended peer and not an interceptor.

This design gives DTLS-SRTP a property SDES lacks. With SDES, the actual SRTP master key sits in the SDP body, so anyone who can read the signaling can decrypt the media, which is why SDES is only safe when SIP signaling is itself wrapped in TLS. With DTLS-SRTP, signaling only carries a fingerprint, which is useless to an attacker: the real key material never leaves the media path and is negotiated fresh for every session. That separation is why WebRTC mandates DTLS-SRTP and forbids SDES entirely.

Where the Keys Come From

After the DTLS handshake finishes, both endpoints run the same key-derivation function, defined in RFC 5764, over the shared master secret to produce the SRTP master keys and salts. The DTLS association can then be kept alive purely as the keying context, while SRTP takes over carrying the actual audio and video. Neither side ever transmitted an SRTP key in the clear, and neither trusted a message it could not verify against the signaling fingerprint.

DTLS vs TLS: What Is the Difference?

DTLS and TLS share the same cryptographic core, the same cipher suites, and the same trust model. The difference is the transport each is built for and, in voice networks, the job each one ends up doing. TLS runs over reliable, connection-oriented TCP and secures SIP signaling. DTLS runs over unreliable, connectionless UDP and, in its DTLS-SRTP form, secures the exchange of media keys.

Property	TLS	DTLS
Transport	TCP (reliable, ordered)	UDP (unreliable, unordered)
Handles packet loss	Relies on TCP	Built-in retransmission
Typical VoIP role	Encrypting SIP signaling (port 5061)	DTLS-SRTP media key exchange
Anti-DoS mechanism	TCP handshake	Stateless cookie exchange
Latency-sensitive	Head-of-line blocking on loss	No head-of-line blocking

The practical takeaway is that the two protocols are complementary rather than competing. A secure WebRTC-to-SIP call commonly uses both at once: TLS protects the SIP signaling on the network side, while DTLS-SRTP handshakes the media keys on the browser side. Neither replaces the other, and an SBC often has to speak both simultaneously on opposite legs of the same call.

DTLS-SRTP at the WebRTC-to-SIP Boundary

DTLS-SRTP is mandatory in WebRTC and effectively universal in browser-based communications, but most SIP carriers and legacy PBXs never adopted it. They rely on SDES over TLS, or on plain RTP where no encryption is negotiated at all. When a browser needs to reach a phone number on a carrier trunk, something has to sit between the two worlds and translate the key exchange. That something is an SBC.

Because a Session Border Controller operates as a back-to-back user agent, it fully terminates the media on each leg and re-originates it independently. On the browser-facing leg it can run the DTLS handshake, verify the fingerprint, and derive SRTP keys the WebRTC way. On the carrier-facing leg it can negotiate SDES over TLS, or convert to plain RTP, or apply whatever the far side supports. The two legs have entirely separate cryptographic contexts, so the browser gets its mandatory DTLS-SRTP without the carrier needing to change anything. This is the same per-leg encryption boundary described in the WebRTC-to-SIP gateway architecture, where media encryption handoff is one of five translation subsystems the gateway performs.

There is more to the boundary than encryption. The same SBC handles the wider set of differences between WebRTC and SIP: ICE termination so the browser’s NAT-traversal candidates resolve to a stable address, codec mediation when the browser offers Opus and the carrier wants G.711, and SIP header normalization so the call looks native on each side. DTLS-SRTP translation is one job among several the gateway performs, but it is the one that keeps media confidential all the way across.

Frequently Asked Questions

Conclusion

DTLS exists because real-time media cannot wait for TCP latency of back and forth transactions, and secure media cannot rely on keys that travel in clear signaling. By bringing the TLS security model to UDP and pairing it with SRTP, DTLS-SRTP solves the key-exchange problem in a way that survives packet loss, resists spoofing, and never exposes a media key to anyone reading the signaling. That combination is why it became the mandatory foundation of WebRTC media security.

The complication in production networks is that browsers speak DTLS-SRTP while most carriers and PBXs do not. Bridging those two worlds without weakening either one is a per-leg encryption problem, and it is exactly the kind of translation a Session Border Controller exists to perform at the network edge.