WebRTC in plain terms

WebRTC is a set of browser APIs for real-time audio, video and data between peers. It has been a W3C Recommendation since January 2021, with the current edition published in October 2024.

Three parts, and it is worth keeping them separate in your head.

The browser can ask for a camera and microphone, and hand you a stream. Permission is the user's, granted per origin, and revocable. Nothing about this part needs a server.

This is where the acronyms live.

ICE is the procedure for finding a path between two devices that are both probably behind routers doing address translation. It gathers candidate routes and tries them.

STUN is a small public service a device asks "what does my address look like from out there?". Cheap to run, cheap to use.

TURN is a relay for when no direct path exists. It carries actual media, so it costs bandwidth, and it is the piece people forget to budget for. A meaningful minority of connections need it, and on restrictive corporate networks that minority is much larger.

A call looks instantaneous and is five separate negotiations. Knowing which one failed is most of debugging, and knowing which one a vendor operates for you is most of buying.

Alongside audio and video, WebRTC carries an arbitrary data channel — peer-to-peer, low latency, no server in the middle. It is underused. Cursor positions, game state, live document edits and file transfer all fit here.

It is not a product. It is a set of primitives. Everything a meeting needs beyond one connection — a room, a participant list, permissions, recording, a lobby — you build or you buy.

It is not signalling. The standard deliberately does not specify how two peers exchange the details needed to connect. That is left to you, which is why every WebRTC tutorial spends most of its time on a WebSocket.

It does not scale to a crowd by itself. Beyond a handful of participants you need a media server. That is not a defect; it is the point at which the architecture changes.

This is the distinction that decides what you are actually buying from a video vendor.

Because it puts a floor under what video should cost. Any vendor pricing a two-person call is pricing something the browser will do for free, plus the operational work of signalling and relay.

That does not make hosted video bad value — the operational work is real, and recording and scale are genuinely hard. But it does mean you should know what the free path would have given you before you pay for the other one.

Three things account for most WebRTC support tickets, and none is the part that looks hard.

Permissions. The user declined the camera prompt once, months ago, and the browser remembers. Your application sees a rejected promise and shows "connection failed", which is both wrong and unactionable. Detect the specific error and say "your browser is blocking the camera — here is how to allow it".

Device selection. A laptop with a docked monitor, a headset and a built-in microphone has several plausible inputs, and the default is frequently the wrong one. A device picker is not a nice-to-have; it is the difference between a call that works and a user who concludes your product is broken.

Networks that fail halfway. ICE succeeds, media flows, and then a network change — wifi to cellular, a VPN connecting — drops it. Handle the reconnection path deliberately, because the default is a frozen picture and no explanation.

The connection exposes statistics continuously, and a small subset predicts a bad call before the user complains: round-trip time, packet loss, and whether the connection is relayed.

Surfacing a simple indicator from those — and, crucially, telling the user which side has the problem — converts an unexplained bad experience into a solvable one. "Your connection is unstable" is actionable. A frozen video is not.

Extended use cases are being worked on that matter for anything beyond a two-person call: access to encoded frames for custom processing, tighter control over congestion behaviour, and machine-learning-adjacent work on media pipelines.

The practical read is that the standard has stopped being a fixed target and is being extended for real-time applications well beyond conferencing.

• Three parts: capture, connection, data. Only the connection needs infrastructure.
• Budget for TURN; it is the one component with a bandwidth bill.
• Most support load is permissions and device selection, not the protocol.
• Surface connection quality, and say which end is at fault.

Peer-to-peer is free and works for most two-party calls on ordinary networks. The costs arrive in two places, and both are operational rather than licensing.

Relays. Some share of calls — a tenth is a common figure, and it is much higher on corporate networks — cannot connect directly and needs a TURN relay. Relayed media is bandwidth you pay for, per minute, on a server you run or rent.

Routing. Beyond about four participants, a mesh where everyone sends to everyone stops scaling. You need a selective forwarding unit, which is a server that receives every stream and forwards the ones each participant needs. That is a real piece of infrastructure with real capacity planning.

Two-party support calls avoid both most of the time. Group calls avoid neither.

WebRTC media is encrypted, but it still travels somewhere, and where the relay sits is a jurisdiction question a regulated buyer will ask.

A vendor SDK with a cloud media path is faster to integrate and puts your customers' media on infrastructure you do not control, in a region you may not have chosen. A self-operated relay keeps it inside a boundary you can name, at the cost of running relays.

Both are defensible. Only one survives a data-residency clause, and the difference is invisible in a feature comparison — which is precisely why it should be the first question rather than the last.