VoIP.info Guide

DTLS-SRTP: separate signaling trust from media keys

Follow the media handshake and identify where encrypted browser audio terminates.

Reviewed 2026-09-07WebRTC standards; browser and server behavior must be checked by versionIntermediateDocumentation based · not lab tested

Two different protection relationships

WSS uses TLS to protect browser signaling to the server. DTLS-SRTP establishes keying for protected real-time media between the negotiated media peers. These relationships can end at different systems. A reverse proxy terminating WSS does not automatically become the media peer. The SDP fingerprint participates in authenticating the DTLS certificate against the signaled expectation. If signaling is compromised, protecting the media transport alone does not solve the identity problem.

Find the first failed connection stage
Working signaling provides session descriptions. ICE checks select a candidate pair, then DTLS establishes media keys. Incoming and outgoing media statistics and local capture or playback determine whether sound reaches the user.

A diagnostic order, not a strict application timeline: capture can start earlier and ICE gathering may be incremental. Successful signaling alone does not prove audio works.

Follow the handshake after ICE

Once ICE selects a usable path, inspect whether the DTLS handshake completes and whether SRTP packets follow. A selected candidate pair with increasing connectivity-check traffic is not the same as successful media keying. Compare the negotiated setup roles, fingerprint and supported media profile. A mismatch after a PBX or gateway rewrite can produce calls that signal successfully but never deliver decodable audio. Do not work around this by stripping security attributes without a supported design.

State the trust boundary accurately

When a PBX decrypts browser media to bridge, record, mix or transcode it, the protected browser leg ends at that PBX. The next leg may use a different security relationship or unencrypted RTP. That is distinct from an application offering end-to-end encryption between participants. Document which systems can access media and keys, and which administrators can retrieve recordings. For troubleshooting, prefer handshake state and counters before collecting sensitive payloads. A security claim should describe the actual termination points rather than relying on a lock icon in the website address bar.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.