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, 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.

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.

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.

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.

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 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.

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.

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.

• 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.