WebRTC in plain terms

WebRTC (Web Real-Time Communication) is a set of building blocks inside browsers and mobile apps for live audio, video and data between two devices. It has been a W3C Recommendation since January 2021, most recently updated in March 2025, and it rests on protocols standardised by the IETF.

Example: a telehealth app lets a patient tap "Join appointment" in the browser and see their doctor — no plug-in, no download. WebRTC is doing the camera access, the connection and the encrypted media. Almost everything else — the waiting room, who may join, the appointment record — is the app's own work.

It has three parts, and it helps to keep them separate.

The browser asks for the camera and microphone and hands the app a stream. Permission belongs to the user, is granted per website, and can be withdrawn. Nothing in this part needs a server.

This is where the acronyms live. Most devices sit behind routers doing NAT (network address translation), which hides their real address. Connecting two of them takes:

• ICE — the procedure for finding a working path between two devices. It gathers possible routes and tries them.
• STUN — a small public service a device asks, "what does my address look like from out there?" Cheap to run.
• TURN — a relay for when no direct path exists. It carries the actual media, so it costs bandwidth, and it is the part people forget to budget for. The share of calls that need it varies widely and is much higher on restrictive corporate networks.

A call looks instantaneous but is several separate steps. Knowing which one failed is most of debugging; knowing which ones a vendor runs for you is most of buying.

Alongside audio and video, WebRTC offers a data channel: a low-latency connection between the two devices for anything else — cursor positions, game moves, live document edits, file transfer. It is underused.

It is not a product. It is a set of building blocks. Everything a meeting needs beyond one connection — rooms, participant lists, permissions, recording, a waiting room — you build or buy.

It is not signalling. The standard deliberately leaves out how two devices find each other and exchange connection details. That is why every WebRTC tutorial spends most of its time on a WebSocket.

It does not scale to a crowd on its own. Beyond a handful of participants you need a media server.

The browser parts are free. Costs arrive in two places, both operational rather than licensing:

• Relays. Calls that cannot connect directly need TURN, and relayed media is bandwidth you pay for, on servers you run or rent.
• Media servers. Group calls need an SFU, which is real infrastructure with real capacity planning.

One-to-one calls avoid both most of the time. Group calls avoid neither. That puts a floor under what a simple two-person call should cost — useful to know when reading a price list — while recognising that hosted services also sell operations, reach, recording and support.

Most WebRTC support tickets are not about the protocol:

• Permissions. The user blocked the camera once, months ago, and the browser remembers. Detect that specific error and say "Your browser is blocking the camera — here's how to allow it", not "Connection failed".
• Device selection. A laptop with a docked monitor, a headset and a built-in microphone has several possible inputs, and the default is often wrong. A device picker is essential, not a nice-to-have.
• Networks that change mid-call. Moving from wi-fi to mobile data, or a VPN connecting, can drop media. Handle reconnection deliberately; the default is a frozen picture and no explanation.

The connection reports statistics continuously. Three predict a bad call before the user complains: round-trip time, packet loss, and whether the call is relayed. A simple indicator built on them — and telling the user which side has the problem — turns an unexplained bad experience into a fixable one.

WebRTC media is encrypted, but it still travels somewhere, and where relays and media servers sit is a jurisdiction question a regulated buyer will ask. A vendor's hosted media path is faster to adopt and often offers regional controls; a self-run relay keeps media within a boundary you name, at the cost of running it. Both are defensible — ask the question early. See peer-to-peer video for the trade-offs.

W3C work on extended use cases covers access to encoded media for custom processing, finer control over congestion behaviour and other needs beyond conferencing. The standard is still being extended for real-time applications of many kinds.

• Peer-to-peer video: what it removes, and what it does not — the next step in this track.
• Latency you can actually feel — why delay matters more than resolution.