---
title: "Peer-to-peer video: what it removes, and what it does not"
summary: "For small calls, a media server is optional. When it stops being optional — and what a hosted video service gives you in exchange for its price — is the whole decision."
canonical: https://cpaas.co/en/learn/video-without-a-vendor
kind: explainer
depth: foundation
origin: original
published: 2026-09-12T16:26:18.899Z
updated: 2026-10-14T16:26:19.451Z
topics: ["Voice & Video", "Architecture", "Fundamentals"]
language: en
---
# 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](https://www.w3.org/TR/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.

## What you still need

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

```diagram:blocks
# What a peer-to-peer call still needs
Signalling | The two sides exchange connection details before they connect. A message-passing job, 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. It carries media, so it carries a bandwidth bill.
The two peers | Audio, video and data flow directly between them when a direct path exists.
> Measure your own relay share rather than trusting a published one. Corporate and hotel networks push it well above optimistic estimates.
```

## Three ways to run video

| Approach | What you run | Good for | Trade-offs |
|---|---|---|---|
| Peer-to-peer you operate | Signalling, STUN, TURN | One-to-one calls with modest feature needs | Breaks down with more participants; no server-side recording; you run and secure the relays |
| Self-hosted media server | All of the above plus an SFU (a server that forwards streams), usually open source | Group calls, recording, full control over where media goes | Real capacity planning, upgrades, monitoring and on-call — a standing engineering commitment |
| Hosted video API | Your app only; the provider runs servers worldwide | Fast launch, mobile SDKs, recording and transcription, global reach | Per-minute cost; media passes through the provider's infrastructure; some dependence on one vendor |

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

```diagram:scale
# How much of the video stack you run
Your app only | Everything
Hosted video API | 1 | The provider runs servers worldwide
Peer-to-peer you operate | 5 | Signalling, STUN and TURN
Self-hosted media server | 9 | All of that plus an SFU — a standing engineering commitment
```

## Where peer-to-peer stops working

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

```diagram:decision
# Does this call still work peer-to-peer?
More than three or four participants? | You need a media server |
Recording, transcription, moderation or streaming to an audience? | Media has to pass through a server |
Very mixed devices and connections in one call? | A media server can adapt one stream for each recipient | Peer-to-peer can work — though the weakest connection sets the ceiling
```

## The relay share decides the bill

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.

## Where the media goes

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.

```diagram:compare
| Peer-to-peer | Self-hosted media server | Hosted service
Where media flows | Between the two devices, when a direct path exists | Where you choose to put the server | In the provider's regions, often pinnable
When a relay is needed | Through whoever runs the TURN server | Through your own relays | Through the provider's relays
What you rely on | Controlling where relays sit | Your own patching, monitoring and audit evidence | Their contracts, certifications and audit reports
```

## What a hosted service gives you for its price

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.

```diagram:checklist
# What the per-minute price usually covers
Relays and media servers in many regions
Mobile SDKs
Adaptation to poor networks
Recording and transcription
Call-quality monitoring
Uptime commitments
Compliance documentation
Support
> Good value without a team ready to run real-time infrastructure around the clock.
```

## A sensible default

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.

## What to ask, whichever way you go

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

## Where to go next

- [Latency you can actually feel](/en/learn/latency-you-can-actually-feel) — the next step in this track.
- [When video belongs in support](/en/learn/when-video-belongs-in-support) — deciding whether to offer video at all.
- [WebRTC in plain terms](/en/learn/webrtc-in-plain-terms) — the building blocks, explained.

## Sources

[^1]: [WebRTC: Real-Time Communication in Browsers](https://www.w3.org/TR/webrtc/) — W3C Recommendation, 13 March 2025
[^2]: [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.