DTLS-SRTP is WebRTC's mandatory media encryption, and it has two cooperating parts. A DTLS handshake (specified in RFC 5763 and RFC 5764) runs first to authenticate the connection and securely establish keys, and then SRTP (the Secure Real-time Transport Protocol, RFC 3711) uses those keys to encrypt and authenticate every individual audio and video packet. Crucially, this is always on: there is no unencrypted mode of WebRTC media, so a developer cannot accidentally ship a clinical call in cleartext.
For a telemedicine product, this matters because it satisfies HIPAA's transmission-security expectation under the Security Rule (45 CFR §164.312) at the level of each network hop, with no extra work — the media is encrypted in transit by default between each pair of connected endpoints.
The boundary to understand, and the most common misunderstanding, is that DTLS-SRTP protects each hop, not the whole journey through a server. When media passes through an SFU or MCU, that server terminates the incoming SRTP, sees the media in the clear, and re-encrypts it for the outbound hop. So while the wire is always protected, a compromise of the media server still exposes the audio and video unless you layer true end-to-end encryption (E2EE) on top, where only the participating endpoints — never the server — hold the keys. Teams that equate "WebRTC is encrypted" with "the server can't see the media" have drawn the boundary in the wrong place.
