Encrypted voice calls and [encrypted video calls] are not sealed by the same machinery that seals a chat message. Messages live in a store-and-forward world, so they are encrypted with a ratcheting protocol before they ever touch a server; live media must survive packet loss and latency budgets measured in milliseconds, so it uses WebRTC's mandated DTLS-SRTP transport encryption instead. That difference is a deliberate engineering trade-off, not a weakness — but it changes exactly what is guaranteed, and this article walks through the boundary with a side-by-side comparison.
Key takeaways
- Every media stream in WebRTC is encrypted in transit using DTLS-SRTP; Ant Media's WebRTC security guide notes that this is mandated per IETF RFC 8827 — there is no unencrypted WebRTC call.
- Message protocols such as Livara's LVR1 use a hybrid post-quantum double ratchet (P-256 ECDH plus ML-KEM-768) and deliver forward secrecy and post-compromise security; call media's DTLS-SRTP is not a ratchet and is not post-quantum.
- In group calls relayed through a media server, the server sits inside the encrypted hop unless extra end-to-end measures are layered on top — Forasoft's DTLS/SRTP explainer spells out this catch for relayed WebRTC calls.
- Call signalling — who is calling whom, which room to join — should not travel over the open channel; in Livara it rides inside ordinary pairwise-sealed messages.
- Routing metadata (sender, destination, delivery timestamps) sits outside both the message encryption and the call encryption; it is what servers need for real-time delivery.
What is DTLS-SRTP, and why do encrypted voice calls use it?
DTLS-SRTP combines two standards: DTLS (Datagram Transport Layer Security), a TLS variant that works over unreliable UDP packets, and SRTP (Secure Real-time Transport Protocol), which applies per-packet encryption to voice and video streams. In WebRTC, a DTLS handshake runs first between the call participants to agree on keys, and those keys then feed SRTP, which encrypts each audio and video packet — the WebRTC security guide at nat.io describes this handshake-then-encrypt flow as the standard sequence for WebRTC media.
The reason live media takes this path is mechanical rather than philosophical. A chat message can be encrypted once, stored, and delivered whenever it arrives; a call is a live stream of thousands of small packets per second that must be decoded within tens of milliseconds. DTLS-SRTP negotiates session keys once per call and then applies fast, lightweight per-packet protection, which fits that constraint. The Ant Media tutorial makes the same point from the builder's side: encryption is on by default for every stream, but knowing where the security is enforced — at the endpoint or at an intermediary — is what determines whether a call is truly private.
How message encryption differs from call encryption
Message encryption is a ratchet. In Livara's LVR1 protocol for direct messages, a P-256 ECDH ratchet and an ML-KEM-768 epoch ratchet run side by side, and every message key is derived from both — a hybrid post-quantum design following NIST's FIPS 203 for the KEM. Each new message uses a fresh key, which yields two properties DTLS-SRTP does not attempt: forward secrecy (a later key compromise cannot decrypt past messages) and post-compromise security (the conversation self-heals after an earlier key compromise), both covered in our guide to post-quantum encryption in messaging.
Call encryption is a session. DTLS-SRTP agrees on keys at the start of a call and protects the media for the call's duration; it does not ratchet per packet, because per-packet key evolution would break the latency budget that real-time audio depends on. If a call cannot be connected, there is nothing to decrypt later — media is not stored the way an attachment is, which is why encrypted attachments follow an entirely separate pattern in how encrypted media storage works.
| Property | Messages (LVR1 / LGS1) | Call media (WebRTC DTLS-SRTP) |
|---|---|---|
| Key agreement | P-256 ECDH + ML-KEM-768 (hybrid) | DTLS handshake with certificate fingerprints |
| Key evolution | Fresh key per message (double ratchet) | One session negotiated per call |
| Forward secrecy / PCS | Yes, by design | Not a ratchet property |
| Post-quantum | Yes (ML-KEM-768, FIPS 203) | No — classical crypto only, do not confuse the two |
| Encryption unit | Each individual message | Each SRTP media packet |
| Payload encrypted | Text, edits, attachments, captions, voice notes | Voice and video in the call |
| Intermediary exposure | Content is unreadable in transit and at rest | Depends: peer-to-peer is endpoint-to-endpoint; a relaying media server is a third point unless extra steps are taken |
Do group encrypted calls stay safe when a media server is involved?
It depends entirely on the topology, and this is the distinction most people miss. In a peer-to-peer call, DTLS fingerprints are exchanged hand-to-hand and SRTP keys live only on the participants' devices. In a group call, most WebRTC applications route media through a server so the stream scales; per Forasoft's DTLS and SRTP explainer, in that configuration "that server can see the audio and video unless you add end-to-end" encryption on top — the encryption has been moved from end-to-end to endpoint-to-server.
One honest limitation: Livara's group call rooms on Android (2–6 people) use WebRTC DTLS-SRTP for call media, which means call media is protected by standard WebRTC transport encryption — not by the message ratchet, and we do not label it post-quantum. Separately, a call's signalling (the invite, the room details) travels as "LCS1", which is delivered as an ordinary pairwise-sealed message — so the invitation conversation is protected like the rest of your chats. Group membership and routing metadata remain server-controlled; the Livara threat model documents exactly who sees what, and our security page lists the boundaries in full.
What does DTLS-SRTP actually verify — and what should you verify?
DTLS proves the handshake to a certificate; pairing that trust with the right human is your job. A protocol can encrypt every packet and still connect you to an impostor if the key exchange was silently substituted. This is why fingerprint verification matters: Livara's safety numbers let two people compare key fingerprints out of band, and our walkthrough of verifying an encrypted chat with safety numbers explains what to do when a number changes.
A few checkable specifics when you audit any messenger's calls:
- Ask where the encryption is enforced. Peer-to-peer, or relayed through a media server that could observe audio? (Ant Media runs through the enforcement points builders must set up — token authorization, TURN/STUN controls, DTLS handshake configuration.)
- Ask whether keys combine two independent exchanges. A single classical handshake breaks once; a hybrid design like Livara's message layer requires both a P-256 ECDH exchange and an ML-KEM-768 encapsulation to fall.
- Ask what lacks proof. Release checksums and published test vectors are verifiable evidence — Livara makes the Android APK independently checkable offline in the Proof Lab — but they are not an independent security audit, and no messenger should claim otherwise.
How do messengers compare on call security — and what should you accept as "good enough"?
Compare messengers on named criteria, not on adjective density: (1) is media DTLS-SRTP end-to-end or endpoint-to-relay in group calls, (2) is signalling carried inside sealed messages or over a plaintext channel, (3) does the message layer (not the call layer) offer ratcheting and post-quantum strength, and (4) is fingerprint verification available for calls' participants. If a vendor markets "end-to-end encrypted calls", ask directly whether group calls are really point-to-point or whether a server sits in the middle — because for most WebRTC deployments, they do. The honest summary for encrypted voice calls in 2026-era tooling: DTLS-SRTP is mandatory, well-tested, and stable; it predates post-quantum cryptography, and that gap between your calls and your messages is the boundary every serious product should state plainly rather than paper over.
Frequently asked questions
Is every WebRTC call automatically encrypted?
Yes — DTLS-SRTP encryption is mandatory for every WebRTC media stream per IETF RFC 8827, so there is no unencrypted WebRTC call. However, "encrypted in transit" is not the same as "end-to-end": in group calls relayed through a media server, the server is inside the encrypted path unless additional end-to-end measures are layered on top.
Are encrypted video calls post-quantum?
Not with current mainstream WebRTC. DTLS-SRTP uses classical cryptography negotiated in a DTLS handshake; post-quantum DTLS is still limited to early adoption in browsers, per Forasoft's status notes on Chrome and libwebrtc. Livara's messages are hybrid post-quantum (P-256 + ML-KEM-768), but we do not make that claim for call media.
What's the difference between DTLS and SRTP?
DTLS is a TLS variant adapted for unreliable UDP transport; it performs the handshake and agrees on session keys between call participants. SRTP is the packet protocol that then uses those keys to encrypt each individual audio or video packet. DTLS sets up the trust and keys; SRTP does the per-second, thousands-of-packets encryption.
Can the server see my voice or video in a call?
In a peer-to-peer call, no — SRTP keys exist only on the participants' devices. In a group call relayed through a media server, the server may sit inside the encrypted hop and can access the media unless the application adds extra end-to-end layers. Ask your messenger which topology it uses for group rooms before assuming privacy.
How do I check who I'm really talking to on an encrypted call?
Use fingerprint verification. Compare safety numbers with the other participant over a trusted out-of-band channel; if the number changes unexpectedly, a key has changed and needs investigating. Livara publishes safety numbers and the boundaries of call protection on its security page, so verification is a two-minute check rather than a trust assumption.
