DTLS-SRTP vs SRTP: WebRTC Security for PBX Admins
When PBX admins talk about “secure calling”, they’re usually referring to two separate layers: signalling security (how the call is set up and controlled) and media security (how the audio/video packets themselves are protected). In classic SIP estates, you can run plain RTP, optionally enable SRTP, or mix-and-match by endpoint. WebRTC changes the ground rules: browsers are designed to default to strong media security, and they do it in a specific way that can surprise SIP environments.
This guide explains the practical difference between “SRTP” as a media format and the two most common keying methods you’ll encounter (DTLS-SRTP and SDES-SRTP), why browsers steer you toward DTLS-SRTP, and what PBX admins should check to keep secure media from breaking calls.
1) SRTP is “encrypted RTP” — the keying method is the real decision
SRTP is the encrypted form of RTP: it protects the confidentiality and integrity of media packets and helps prevent replay attacks. What SRTP does not define is how the endpoints agree on the keys. In practice, the two keying models you’ll see most often are:
- SDES-SRTP: the SRTP keys are delivered in the SDP (signalling path).
- DTLS-SRTP: the SRTP keys are negotiated via DTLS on the media path.
That difference is why two devices can both claim “SRTP support” and still fail to interoperate.
2) Why browsers prefer DTLS-SRTP (and what breaks when the network is unfriendly)
WebRTC’s security model is intentionally opinionated: it assumes modern cryptographic protection for media and a negotiation flow that is resilient to common attack classes. The most useful “ground truth” for PBX admins is the IETF security architecture for WebRTC, which explains how the pieces fit and why the design is intentionally strict: WebRTC Security Architecture (RFC 8827).
In practical terms, WebRTC endpoints typically establish SRTP keys using DTLS. If DTLS cannot complete cleanly (due to blocked UDP, aggressive middleboxes, broken NAT behaviour, or incorrect media anchoring), you can see the classic symptoms: calls connect, signalling looks normal, but media never becomes usable.
3) DTLS-SRTP in one paragraph (what it is and why it’s common)
DTLS-SRTP uses a DTLS handshake on the media path to establish keying material for SRTP. It avoids shipping SRTP keys inside SDP and aligns well with browser security assumptions. The canonical reference is: DTLS-SRTP key establishment (RFC 5764).
For PBX admins, the takeaway is simple: if you want browser calling to behave reliably, you generally need a media layer that can handle DTLS-SRTP properly on the WebRTC side, even when the SIP side expects something else.
4) SDES-SRTP: where it fits (and the dependency it creates)
SDES-SRTP can work well in controlled SIP environments, particularly when you enforce SIP over TLS end-to-end so the SDP (and therefore the keys) are never exposed in transit. The operational risk is that SDES ties media security directly to signalling security. If signalling isn’t strongly protected, SDES can undermine the entire point of “encrypted media”.
This is why many modern WebRTC deployments favour DTLS-SRTP: it avoids putting SRTP keys inside SDP and reduces reliance on signalling confidentiality for media secrecy.
5) What to check on Asterisk/PJSIP: encryption modes must actually match
If you run Asterisk with PJSIP, the most important operational point is that “SRTP enabled” isn’t enough—you need to confirm the actual encryption/keying mode being offered and accepted. Use the official configuration reference as your baseline when validating settings and behaviour: Configuring res_pjsip (Asterisk documentation).
When troubleshooting, confirm three things per call leg:
- Policy: is media encryption required, preferred, or optional?
- Compatibility: is the peer expecting DTLS-SRTP, SDES-SRTP, or plain RTP?
- Network viability: can the DTLS handshake and SRTP actually traverse NAT/firewalls as deployed?
A surprising number of “random” call failures are simply a mismatch between a strict policy on one side and optional/unsupported capability on the other.
6) Why secure media issues often masquerade as “one-way audio”
One-way audio is often treated as a firewall/RTP port-range problem (and it frequently is). With WebRTC in the mix, you add another common class of failure: signalling completes, but the SRTP keying never finalises (DTLS doesn’t complete), so audio never becomes usable on one side. To debug this properly, you want evidence from both SIP logs and media analysis.
For media-side validation, Wireshark’s RTP tooling is one of the quickest ways to stop guessing: RTP analysis in Wireshark (User’s Guide).
7) NAT traversal is still the bedrock: TURN matters for real networks
Even with perfect crypto settings, secure media will fail if the network won’t pass the packets. In enterprise and hospitality networks, TURN is often the difference between “works on my desk” and “works for everyone”. For a practical, admin-readable reference on why TURN exists and how it fits into ICE, the WebRTC project’s docs are a strong starting point: TURN server overview (webrtc.org).
If you need a deeper but still readable explanation of NAT behaviours, candidate selection, and why traversal fails in practice, this reference is excellent: WebRTC for the Curious (PDF).
8) Practical deployment rule: bridge the models, don’t force endpoints to pretend
Most PBX environments end up with a mixed estate: browsers that expect DTLS-SRTP, SIP phones that may prefer SDES-SRTP (or none), and trunks/SBC policies that vary by carrier and geography. The stable approach is to treat secure media as an interoperability layer: terminate and negotiate securely where required, translate where necessary, and keep policies explicit so “secure calling” doesn’t become “unpredictable calling”.
9) A quick checklist for “secure WebRTC-to-SIP” without breaking calls
- Choose your encryption policy per leg (required vs optional) and document it.
- Confirm keying compatibility (DTLS-SRTP vs SDES-SRTP vs RTP) for every endpoint class.
- Validate network viability (UDP reachability, NAT behaviour, TURN availability for hostile networks).
- Inspect failures with evidence (SIP logs + Wireshark RTP/DTLS behaviour) before changing configs.
- Keep media anchoring consistent so you don’t create asymmetric paths that fail unpredictably.
For more articles like this, visit SoftpageCMS.
