DTLS-SRTP Encryption

Configure DTLS-SRTP media encryption with auto-generated certificates, fingerprint verification, and dual-offer mode for maximum compatibility.

DTLS-SRTP encrypts RTP media by performing a DTLS handshake directly on the media transport path. Unlike SDES where keys are exchanged in the SDP, DTLS derives encryption keys from a secure handshake — meaning keys are never exposed in signaling messages. This is the mandatory encryption method for WebRTC and the recommended approach for modern SIP systems.

How It Works

During SDP offer/answer, both endpoints exchange certificate fingerprints via a=fingerprint attributes
After SDP negotiation, a DTLS handshake runs on the same UDP port as RTP media
Both sides verify the received certificate matches the fingerprint from the SDP
SRTP encryption keys are exported from the DTLS handshake result
All subsequent RTP/RTCP packets are encrypted using the derived SRTP keys
The DTLS connection is closed after key export — it is no longer needed

SDP Example

m=audio 10000 UDP/TLS/RTP/SAVP 0
a=rtpmap:0 PCMU/8000
a=fingerprint:sha-256 4A:1B:2C:3D:4E:5F:60:71:82:93:A4:B5:C6:D7:E8:F9:...
a=setup:actpass
a=rtcp-mux

The a=fingerprint line contains the SHA-256 hash of the endpoint's certificate. The remote endpoint verifies this fingerprint against the certificate received during the DTLS handshake.

Auto-Generated Certificates

CallMeter automatically generates a fresh ECDSA P-256 self-signed certificate for each endpoint. You do not need to upload or manage certificates for DTLS-SRTP.

Algorithm: ECDSA with P-256 curve
Validity: 24 hours (regenerated on worker restart)
Fingerprint: SHA-256, included in every SDP offer

The short validity period follows RFC 5763 Section 5 recommendations for self-signed certificates in DTLS-SRTP.

SRTP Method Configuration

The SRTP method setting controls which key exchange mechanisms are included in the SDP offer. This is a bitmask with four possible values:

Value	Name	SDP Behavior
0	Legacy	SDES keys in SDP (`a=crypto`). No DTLS. Backward compatible with pre-DTLS systems.
1	SDES Only	SDES keys in SDP. Profile: `RTP/SAVP`. Use when the remote only supports SDES.
2	DTLS Only	DTLS fingerprint in SDP. Profile: `UDP/TLS/RTP/SAVP`. Use when the remote supports DTLS.
3	Dual Offer	Both SDES keys AND DTLS fingerprint in the same SDP. The answerer chooses which to use. Maximum compatibility.

Dual Offer Mode

When set to 3 (Dual Offer), the SDP includes both a=crypto lines (for SDES) and a=fingerprint (for DTLS):

m=audio 10000 UDP/TLS/RTP/SAVP 0
a=rtpmap:0 PCMU/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:base64key...
a=fingerprint:sha-256 4A:1B:2C:...
a=setup:actpass
a=rtcp-mux

The answering endpoint picks whichever method it supports:

If it supports DTLS, it responds with a=fingerprint and no a=crypto
If it only supports SDES, it responds with a=crypto and no a=fingerprint
Either way, the call succeeds with encryption

Use Dual Offer for interoperability testing

Dual Offer is the safest choice when you do not know the remote endpoint's capabilities. It maximizes the chance of a successful encrypted call while preferring the stronger DTLS method when available.

DTLS Setup Role

The a=setup attribute in SDP determines which endpoint acts as the DTLS client and which acts as the server:

Value	Meaning
`actpass`	Willing to be either client or server (used in offers)
`active`	Will initiate the DTLS handshake (client role)
`passive`	Will wait for the DTLS handshake (server role)

CallMeter offers actpass and adapts based on the answer.

RTCP-MUX Requirement

DTLS-SRTP uses the same UDP port for the DTLS handshake, RTP, and RTCP. When DTLS-SRTP is enabled, RTCP-MUX is automatically activated on the corresponding track. This is standard behavior per RFC 5764 — the DTLS association is bound to a single transport address.

Security Advantages Over SDES

Property	SDES	DTLS-SRTP
Key exchange	In SDP (plaintext)	Via DTLS handshake (encrypted)
Keys visible to SIP proxies	Yes	No
Perfect forward secrecy	No	Yes (with ephemeral keys)
Certificate verification	No	Yes (fingerprint in SDP)
WebRTC compatible	No	Yes (mandatory)

When to use SDES instead

SDES remains the right choice when testing systems that need to inspect or re-encrypt media (session border controllers, lawful intercept, call recording platforms). These systems require access to SRTP keys, which DTLS-SRTP does not provide to intermediaries.

Next Steps

SDES-SRTP — SDP-based key exchange for legacy systems
SRTP Methods Reference — Detailed bitmask and profile mapping
Media Encryption Issues — Troubleshoot DTLS handshake failures

DTLS-SRTP Encryption

On this page