--- title: "Video without a vendor: what peer-to-peer actually removes" summary: "For small calls, the media server is optional. Understanding when it stops being optional is the whole decision." canonical: https://cpaas.co/en/insights/video-without-a-vendor kind: explainer depth: foundation origin: original published: 2026-08-07T11:34:07.986Z updated: 2026-09-08T11:34:08.091Z topics: ["Voice & Video", "Architecture", "Fundamentals"] language: en --- # Video without a vendor: what peer-to-peer actually removes Browsers can send audio and video directly to each other. That capability is standardised as [WebRTC](https://www.w3.org/TR/webrtc/), a W3C Recommendation, and it is present in every modern browser without a plugin or an SDK. This means a two-person video call can happen with no media passing through anyone's servers. ## What you still need Peer-to-peer does not mean serverless. You need: - **Signalling.** The two parties must exchange connection details before they can connect. This is a small message-passing problem, not a media problem — a WebSocket is enough. - **STUN.** A tiny service that tells a device what its public address looks like from outside. - **TURN, sometimes.** When a network refuses direct connections — strict corporate firewalls, some mobile carriers — the media must be relayed. TURN is that relay, and it does carry media. So the honest claim is not "no servers". It is: **no media server, most of the time**. ```diagram:blocks # What a peer-to-peer call still needs Signalling | The two parties exchange connection details before they can connect. A message-passing problem, not a media one. STUN | A small public service that tells a device what its address looks like from outside. Cheap to run. TURN | A relay for when no direct path exists. This one carries media, so it carries a bandwidth bill. The two peers | Audio, video and data flow directly between them. No server sees the media. > Measure your own relay share rather than trusting a published one. Corporate and hotel networks push it far above the optimistic figure. ``` ## Where it stops working Peer-to-peer scales badly with participants. Each additional person means another connection from every existing person — the connection count grows quadratically, and both bandwidth and CPU follow. Three or four people is usually fine. Eight is not. Above that you need a media server to fan the streams out, and now you are back to running infrastructure or buying it. You also lose anything that requires the media to pass somewhere: server-side recording, transcription, live streaming out to an audience. ## Why the choice matters beyond cost The compelling argument is often not price. It is **data residency**. "Where does the video go?" is a question with a crisp, verifiable answer in a peer-to-peer architecture: between the two participants, and nowhere else. In a hosted architecture the answer is a contractual assertion about someone else's infrastructure. For healthcare, legal, financial and government work, that difference can decide the procurement — and it is the kind of claim a buyer can verify by inspection rather than trust. ## The practical design Build the interface so the backend is swappable, and default to the peer path for small calls, falling back to a media server when the participant count or the feature set demands one. That way the common case costs nothing and leaks nothing, and the uncommon case still works. ## The relay share, and why it decides your bill The number that governs the cost of a self-hosted video path is what proportion of connections need TURN relay, because relayed calls carry real bandwidth and direct ones carry none. It is not a constant. It rises sharply on restrictive corporate networks, symmetric NAT, some mobile carriers and most hotel and conference wifi — which is to say, exactly the networks a business audience uses. Any plan built on the optimistic figure will be wrong in the direction that costs money. Measure it rather than assuming: log per session whether the connection was direct or relayed, and read the ratio for your own users. It is a one-line addition and it turns a guess into a budget. ## Signalling is a small problem worth treating as one The part people over-build. Two peers need to exchange connection descriptions before media flows, and that is a message-passing problem — a WebSocket, a room concept, and a way to know who is in it. Resist letting it grow. Once signalling starts holding presence, permissions, chat, recording state and participant metadata, you have written a media server's control plane without meaning to, and you now maintain it. ## Where the architecture stops being a choice The peer path stops being viable at a specific, predictable point, and it is worth naming so nobody discovers it in production: **Participant count.** Each additional person adds a connection to every existing one, so bandwidth and CPU climb quadratically. Three or four is comfortable. Eight is not. **Server-side anything.** Recording, transcription, moderation, streaming out — all require the media to pass somewhere. **Heterogeneous devices.** With a media server you can send one high-quality stream and let the server adapt it per recipient. Peer-to-peer, the weakest device in the call sets the ceiling for everyone. ## What to take away - The browser gives you media capture, peer connection and a data channel for free. - You still need signalling and STUN, and sometimes TURN — which is the part that costs. - Measure your own relay ratio rather than trusting a published one. - Data residency, not price, is usually the argument that wins on-premise video. ## Sources - [WebRTC: Real-Time Communication in Browsers](https://www.w3.org/TR/webrtc/) — W3C Recommendation, 8 October 2024 - [WebRTC Extended Use Cases](https://www.w3.org/TR/webrtc-nv-use-cases/) — W3C --- 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.