Peer-to-peer video: what it removes, and what it does not

Modern browsers can send audio and video directly to each other. The technology is called WebRTC, a W3C standard built into every major browser and available to mobile apps through open-source libraries.

So a two-person video call can happen with no media passing through anyone's media server. Whether that is the right design for you depends on what else you need. This piece sets out the trade-offs on both sides.

Peer-to-peer does not mean serverless. You need:

• Signalling — a way for the two sides to exchange connection details before they connect. It is a small message-passing job (a WebSocket is enough), not a media problem.
• STUN — a tiny service that tells each device what its public internet address looks like from outside.
• TURN, some of the time — a relay for when networks block direct connections (strict corporate firewalls, some mobile networks, many hotel and conference wi-fi networks). TURN carries the media itself, so it carries a bandwidth bill.

The accurate claim is therefore "no media server, most of the time", not "no servers".

None of these is "the right answer". They suit different call sizes, features, team capacities and compliance needs.

Participant count. In a "mesh", every participant sends their stream to every other. Each new person adds a connection to everyone already there, so bandwidth and processing climb fast. Two is easy; three or four is often fine on good connections; beyond that you need a media server.

Anything on the server side. Recording, transcription, moderation and live streaming to an audience all require media to pass through a server.

Mixed devices and networks. With a media server, one participant can send a single high-quality stream and the server adapts it for each recipient. Peer-to-peer, the weakest device or connection in the call tends to set the ceiling for everyone.

For a self-run setup, the number that governs cost is the share of calls that need TURN, because relayed calls carry real bandwidth and direct ones carry none. Published estimates vary, and the share rises sharply on exactly the networks business users sit on.

Measure it rather than assume it: log for each call whether it connected directly or via a relay, and read the ratio for your own users. It is a small change that turns a guess into a budget.

Data residency — where customer data physically travels and is stored — matters in healthcare, legal, finance and government. Both approaches have a story here, and neither is automatic:

• Peer-to-peer: when a direct path exists, media flows only between the two devices, which is easy to explain and verify. When a relay is needed, media passes through whoever runs the TURN server, so you need to control where relays sit.
• Self-hosted media server: you choose the location, and you also own the security patching, monitoring and evidence auditors will ask for.
• Hosted service: many providers let you pin media to specific regions and supply contracts, certifications and audit reports. You are relying on their controls rather than operating your own.

WebRTC media is always encrypted in transit. With a media server in the middle, though, that server can usually access the media unless extra end-to-end encryption is added — a question worth asking of any design.

It is easy to underestimate what you take on by running video yourself. A hosted service typically provides relays and media servers in many regions, mobile SDKs, adaptation to poor networks, recording and transcription, call-quality monitoring, uptime commitments, compliance documentation and support. If you do not have a team ready to run real-time infrastructure around the clock, that can be good value.

Equally, if your calls are mostly one-to-one, your features are simple and you have the skills, a self-run peer-to-peer path can be cheap and keep media off third-party servers most of the time.

Design your application so the video backend is swappable. Start with whichever option matches your call size, features, compliance needs and team capacity today, and know in advance the trigger that would make you change — more participants, recording, a new market with residency rules.

• Where can media travel, including when a relay is used? Can we restrict it to specific regions?
• What happens to call quality on restrictive corporate networks?
• Who can access media in the middle, and is end-to-end encryption available?
• What does recording add in cost, consent handling and retention?

• Latency you can actually feel — the next step in this track.
• When video belongs in support — deciding whether to offer video at all.
• WebRTC in plain terms — the building blocks, explained.