How Encrypted Voice and Video Calls Work: WebRTC, DTLS-SRTP, TURN
How encrypted voice and video calls really work: WebRTC, DTLS-SRTP, TURN relays and the call setup problem, and how VOIDEX seals the SDP in every call.
A message is a small object that can be sealed, sent and opened at leisure. A call is a different animal. Audio and video are a continuous stream of packets that must arrive within a fraction of a second, over networks that were never designed to make that easy. Encrypting a call well means solving a transport problem and a trust problem at the same time.
This guide walks through how modern encrypted calls actually work: the WebRTC framework, the DTLS-SRTP handshake that protects the media, the relays that carry calls through firewalls, and the quiet weak point that sits in the call setup. It closes with how VOIDEX handles each of those pieces in VOIDEX Messenger.
The building blocks: WebRTC
Most modern browser and app calling is built on WebRTC, a set of standards developed at the W3C and the IETF that lets two endpoints exchange real-time audio, video and data. WebRTC is widely deployed and well studied, and it makes one important decision for everyone who uses it: media is always encrypted. There is no unencrypted mode.
A WebRTC call involves three jobs:
- Signalling. Before a call starts, both sides must describe what they can do: which codecs, which network addresses, which encryption fingerprints. These descriptions are written in the Session Description Protocol, SDP, and exchanged through some channel the application chooses, usually its own server.
- Connectivity. The two devices must find a network path to each other, which is harder than it sounds when both are behind home routers, mobile carriers or corporate firewalls.
- Media. Once a path exists, the audio and video flow, encrypted, for the length of the call.
DTLS-SRTP: how the media is protected
The media in a WebRTC call is carried by SRTP, the Secure Real-time Transport Protocol, defined in RFC 3711. SRTP encrypts and authenticates each audio and video packet efficiently enough for live conversation.
SRTP needs keys, and those keys are agreed through DTLS, a version of TLS adapted for the kind of unreliable packet delivery that real-time media uses. The combination, specified in RFC 5764, is called DTLS-SRTP. The two devices perform a DTLS handshake directly with each other, derive fresh SRTP keys from it, and use those keys to protect the media.
Because the keys come from a handshake between the two endpoints, the server that helped set up the call does not receive them. That is the good news. The catch lies in how each device knows it is shaking hands with the right partner.
The fingerprint problem
In WebRTC, each device typically uses a self-generated certificate for the DTLS handshake. There is no certificate authority vouching for it. Instead, each side puts a fingerprint of its certificate into its SDP description, and the other side checks that the certificate it sees during the handshake matches that fingerprint.
Now recall who carries the SDP: the signalling server. If that server is malicious, compromised or compelled, it can rewrite the descriptions in flight. It could replace both fingerprints with fingerprints of certificates it controls, then place itself between the two callers, completing one DTLS handshake with each. Both sides would see a valid, encrypted call. Both would be talking to the man in the middle.
Nothing on either screen would reveal it. The padlock icon, the connection status and the call quality would all look normal, because from each device's point of view the handshake succeeded exactly as designed. The only difference is that the certificate it checked was chosen by the server rather than by the person on the other end.
This is not a flaw in DTLS-SRTP. It is a reminder that encryption is only as trustworthy as the way keys are authenticated. For a call, that authentication runs through the SDP, so the SDP deserves the same protection as the messages themselves.
Getting through the network: STUN and TURN
Connectivity has its own tools. ICE, Interactive Connectivity Establishment, gathers candidate network addresses and tests which ones work. STUN servers help a device learn its public address. When no direct path can be found, which is common on mobile networks and in offices, the call is relayed through a TURN server, defined in RFC 8656.
A TURN relay forwards packets it cannot decrypt, since the media is still protected by DTLS-SRTP end to end. What a relay can see is traffic shape: that a call is happening, between which network addresses, for how long and at roughly what bitrate. That is metadata, and it is why who operates the relay matters. A call routed through a third party's infrastructure shares that metadata with the third party. We discuss the wider issue in metadata is the message.
What good call security looks like
Putting these pieces together, a well-designed encrypted calling system should:
- Encrypt all media end to end, which WebRTC does by default with DTLS-SRTP.
- Authenticate the call setup, so the signalling server cannot swap fingerprints and sit in the middle.
- Tie the call to the identities you already trust, the same keys that protect your messages.
- Control the relay path, so call metadata does not leak to outside providers.
- Recover gracefully on poor networks, because a call that drops every minute pushes people towards less private tools.
How VOIDEX secures calls
Voice and video calls in VOIDEX Messenger use WebRTC with DTLS-SRTP for the media, so the audio and video are encrypted between the devices on the call.
VOIDEX then closes the fingerprint gap. The call setup, the SDP that carries each device's fingerprint, is sealed under the conversation's end-to-end key before it leaves the device. The server relays that sealed description without being able to read or rewrite it, so it cannot swap in its own fingerprint and place itself in the middle of the call. A call is therefore authenticated by the same keys that protect the conversation's messages.
Those keys are strong. VOIDEX direct messages begin with a hybrid post-quantum key agreement, X25519 combined with ML-KEM-768, and identities are signed with hybrid Ed25519 and ML-DSA-65 signatures. Every device key change is recorded in a public, append-only log that clients check before trusting a key, as described in key transparency. For the background on why the hybrid approach matters, see hybrid post-quantum encryption.
Finally, calls are relayed through VOIDEX's own TURN relay rather than a third-party service. The relay forwards encrypted packets it cannot open, and the metadata a relay inevitably sees stays within VOIDEX infrastructure instead of being shared with an outside provider.
Calls are available across the VOIDEX web app and the Windows and Mac desktop apps, described on the apps page. The complete design, including where calls fit in the wider system, is set out in the public security report, and the cryptographic core is open source at github.com/voidexbycnota/voidex-crypto.
The limits worth knowing
No encrypted call can protect against everything. If a device is compromised, the microphone and camera are compromised with it. Someone in the room can hear your side of the conversation. And a relay, any relay, learns that a call took place and how long it lasted, even when it learns nothing about what was said.
What encryption can do is remove the network and the provider from the list of parties who can listen. Doing that properly means protecting not only the media, which WebRTC already does, but also the setup that decides whose keys the media is locked to.
The quiet part of a call
Most people judge a call by whether it connects and whether the picture is sharp. The security that matters happens in the seconds before either of those things: two devices describing themselves, proving who they are and agreeing on keys. When that exchange is sealed as carefully as a message, the call that follows is a private one.
VOIDEX is invite-only. Request access to make calls where the setup is sealed as tightly as the conversation, or explore VOIDEX encryption in full.
Sources
Enter VOIDEX
VOIDEX is invite-only and free, with no ads and no trackers. Messages are protected by hybrid post-quantum encryption (X25519 with ML-KEM-768) and checked against a public key transparency log. VOIDEX runs in your browser and as apps for Windows and Mac, with iPhone and Android on the way.
Explore the Voidverse
VOIDEX is one private universe: post-quantum encrypted messaging, an anonymous social layer, short video, collectibles and a private window onto the web.
Keep reading
Disappearing Messages, Screenshots and Delete: An Honest Guide
How disappearing messages, screenshot control, editing and delete for everyone really work, what they protect, and the limits no app can remove.
End-to-End Encryption Explained: Transport, At Rest and True E2E
What end-to-end encryption really means, how it differs from transport and at-rest encryption, and what it can and cannot protect. A clear guide.
Forward Secrecy and the Double Ratchet, Explained Clearly
Forward secrecy and post-compromise security explained: how the Double Ratchet gives every message its own key, and how VOIDEX adds post-quantum re-keying.