--- title: "WebRTC in plain terms" summary: "What the browser gives you for free, what it does not, and the three acronyms you cannot avoid." canonical: https://cpaas.co/en/insights/webrtc-in-plain-terms kind: explainer depth: foundation origin: original published: 2026-08-01T11:34:07.986Z updated: 2026-09-08T11:34:08.103Z topics: ["Voice & Video", "Architecture", "Fundamentals"] language: en --- # 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](https://www.w3.org/TR/webrtc/) since January 2021, with the current edition published in October 2024. Three parts, and it is worth keeping them separate in your head. ## Getting media 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. ## Connecting to a peer 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. ```diagram:flow # From tapping call to hearing a voice Signalling | The two sides exchange what they support and where they are. Not part of WebRTC — you build or buy this. Discovery | STUN tells each side its public address. Cheap, stateless, and works for most networks. Traversal | Where symmetric NAT or a strict firewall blocks a direct path, a TURN relay carries the media instead. Negotiation | Codecs, resolutions and encryption keys are agreed. This is where a capability mismatch shows up. Media flows | Peer to peer where possible, through the relay where not. Encrypted either way, always. > Steps one and three are the ones with a running cost. Everything else is a browser API and is free. ``` ## Moving data 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. ## What WebRTC is not **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. ```diagram:compare | In WebRTC | Not in WebRTC Media transport | Encrypted peer-to-peer audio, video and data | The servers when peer-to-peer is impossible Codecs and negotiation | The mechanism for agreeing them | Which ones your call quality actually needs Encryption | Mandatory, end to end on the media path | Key management across more than two participants Signalling | Nothing at all | How the two sides find each other — entirely yours Multi-party | Nothing | An SFU to route more than a handful of participants Recording | Nothing | Storage, consent, retention and jurisdiction > The right-hand column is the product. That is why "we use WebRTC" tells you almost nothing about what a vendor operates. ``` ## Why it matters commercially 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. ## What you will actually spend time debugging 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 quality signals worth surfacing 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. ## Where the standard is going 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. ## What to take away - 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. ## Where the cost actually is 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. ## Why this matters for data residency 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. ## Sources - [WebRTC: Real-Time Communication in Browsers](https://www.w3.org/TR/webrtc/) — W3C Recommendation, 8 October 2024 --- Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.