How Secure Are Browser Calls? DTLS, SRTP, and What Actually Protects Your Audio
Technical · 2026-07-29 · 7 min read
The question every IT-minded buyer should ask
When a customer talks to your business through a website call button, that conversation might include health details, financial information, or a child's name and school. So before adding any calling widget, the right question is: who can hear this? The good news is that browser calling is built on WebRTC — a standard developed in the open, implemented by every major browser, and encrypted by design. Unlike traditional phone calls, which cross networks that may or may not encrypt them, a WebRTC call cannot even be established without encryption. Here's how that works, in plain language.
DTLS-SRTP: the handshake and the seal
Two protocols do the heavy lifting. DTLS (Datagram Transport Layer Security) is the same family of cryptography as the padlock in your browser's address bar, adapted for real-time media. At the start of every call, the two endpoints perform a DTLS handshake — agreeing on encryption keys that only they know. Those keys then drive SRTP (Secure Real-time Transport Protocol), which encrypts every packet of audio in transit. An eavesdropper on the network — a coffee-shop Wi-Fi snoop, a compromised router — sees only ciphertext. This isn't an optional setting a vendor can forget to enable: browsers refuse unencrypted WebRTC media, full stop.
What about the servers in the middle?
Real networks have firewalls and NAT, so calls often travel via servers: STUN helps devices discover their public address, TURN relays media when a direct path is impossible, and platforms like WebCallHub route audio through a media server so calls connect reliably and features like transcription work. The honest technical answer is that a TURN relay only ever forwards encrypted packets — it never has the keys. A media server that provides features like recording or transcription does process audio, which is exactly why it matters where those servers run and under what law. WebCallHub's stack is EU-hosted and GDPR-first: your call data lives with the platform you chose, not scattered across third-party services in unknown jurisdictions.
Security questions to ask any calling vendor
Five questions separate serious vendors from the rest. One: is media encrypted end-to-end in transit with DTLS-SRTP? (For WebRTC, the answer must be yes — verify they can explain it.) Two: where are the media and data servers hosted, and which privacy law applies? Three: who can access recordings and transcripts, and how is retention controlled? Four: does the signaling layer (the part that sets calls up) run over TLS as well? Five: what happens to your data if you leave? Clear answers to these matter more than any badge on a pricing page.
Security you don't have to configure
The quiet advantage of browser calling for a small business is that the hard parts ship pre-configured. There's no PBX to patch, no SIP trunk credentials to leak, no desk phones with default passwords. The browser enforces encryption; the platform manages certificates and keys. With WebCallHub you add one script tag, and every call your visitors make is encrypted in transit from their browser to yours — the same protection whether you're a two-person consultancy or a fifty-agent support team.