WebRTC, Explained Without Jargon: Why the Hard Part Isn't the Audio

Two people, one page, and a voice that has to get from one to the other

Someone asked me recently what I actually work on, so here's WebRTC with no acronyms after this sentence — and then, because a blog post can afford what a LinkedIn post can't, with every acronym explained once we need it.

Two people open a web page. You want their voices to travel between them. That sounds like it should be simple — it's just sound, over the internet, between two computers that are both already online. The complication is that the two computers don't know how to find each other, and by the time you fix that, you've built most of what makes this hard.

The two-server way, and why it isn't free

The obvious way to connect two browsers is to route everything through a server in the middle: browser A sends audio up to a server, the server sends it down to browser B. It works, and it's the model the phone network has used for a century. But that server has to sit physically close to both people or the round-trip delay becomes audible — and every conversation on your platform now needs a slice of server capacity for as long as it lasts. That cost scales with your busiest hour, not your average one.

The clever way: let the browsers introduce themselves

The alternative is to let the two browsers talk to each other directly, peer to peer, with no audio server in the middle at all. This is the promise WebRTC — Web Real-Time Communication, the open standard built into every modern browser — is best known for. The problem is that neither browser knows the other's address. Both are usually sitting behind a home router, an office firewall, or a mobile carrier's network address translation — pieces of infrastructure that were built specifically to stop an unknown computer from reaching in uninvited. The two browsers are, from each other's point of view, unreachable by default.

The hard part isn't the audio, it's the introductions

So before a single word of audio moves, the browsers run a small negotiation, and this is the part tutorials tend to skip past: here are all the addresses I might be reachable on — try them, and tell me which one worked. This process has a name, ICE (Interactive Connectivity Establishment), and it leans on two helper services. STUN is the polite one: a lightweight server that simply tells your browser what its own public address looks like from the outside, the way asking a stranger "what do I look like from across the street" would. TURN is the fallback for when direct contact genuinely isn't possible — a relay server that both sides can reach, forwarding traffic between them. TURN is the two-server model again, but used only when it's actually needed instead of by default, which is why a well-built system tries the free, direct path first and pays for a relay only on the calls that require one.

Agreeing on the rules before a word is spoken

Finding a reachable address isn't the end of the introduction — the two sides still have to agree on the terms of the call itself: which audio format to use, what the media should be labeled, which of the addresses they just discovered to actually use. That exchange is called the offer/answer negotiation, carried in a format called SDP (Session Description Protocol) — one side proposes a session description, the other answers with what it can actually support, and the two converge on a shared plan before either one sends anything.

Locking the door

Only after the two sides know how to reach each other and have agreed on the terms do they encrypt the channel — a handshake called DTLS-SRTP, the same family of cryptography that puts the padlock in your browser's address bar, adapted for real-time audio and video. This isn't an optional step a developer can forget to switch on: browsers simply refuse to send WebRTC media unencrypted, full stop. Whatever else is true about a given calling product, the audio between two browsers is encrypted in transit by construction, not by configuration.

All of this, before the ring even finishes

Address discovery, negotiation, encryption — three separate protocols, two helper servers, and a back-and-forth exchange, and all of it completes in the time it takes a phone to ring once. That's the part I underestimated when I first started building on top of this stack: I assumed the hard engineering problem in real-time voice would be the audio itself — compression, quality, echo cancellation. It turned out the audio is the easy, well-solved part. The hard part is the introduction two strangers' browsers have to make to each other before they're allowed to say anything at all.

Where this shows up if you're evaluating a calling vendor

If you're the one deciding whether to trust a product with this plumbing, the introductions are also where the real engineering differences hide. Does the platform try a direct connection before falling back to a relay, or does it relay every call by default and pass the server cost on to you? Is the relay itself run somewhere you'd be comfortable with your customers' conversations touching? Even a system that markets itself as peer-to-peer often still needs somewhere for the introduction — and sometimes the call itself — to happen; our own platform, for instance, deliberately routes call audio through our media server rather than pretending every call finds a clean direct path, which is a real trade-off, not a marketing claim, and one worth asking any vendor about directly rather than taking on faith.

For the practical, business-facing version of this question — what browser-to-browser calling actually replaces, and how it's secured end to end — see "What Is Browser-to-Browser Calling (WebRTC)?" and "How Secure Are Browser Calls?" on this blog. This piece is the mechanism; those are the decision.