The idea · 8 min read
What peer-to-peer video calling actually means
Most video apps send your camera to a server first. Peer-to-peer sends it straight to the other person. Here's the real difference, and what each one costs you.
Nearly every video call you have ever made took a detour. Your camera went up to a company's server, was decoded, sometimes re-encoded, and sent back down to the person you were talking to — who may well have been sitting in the same room.
A peer-to-peer call skips that. Your device sends the video to their device. That's the whole difference, and almost everything else follows from it.
The two shapes a call can take
In a server-routed call, both people connect to a machine in a data centre. That machine receives every stream and forwards it on. If it merely forwards packets it is called an SFU (selective forwarding unit); if it decodes and mixes streams into one composite picture it is an MCU. Either way, your video exists, however briefly, on hardware you don't control.
In a peer-to-peer call, the two devices find a route to each other and send media along it directly. Nothing in between stores or decodes it. There is no third copy, because there is no third participant.
Peer-to-peer still needs a server. Just not for your video.
This is the part that gets muddled, often deliberately.
Two browsers cannot call each other out of nowhere. Neither knows the other's address, which codecs it speaks, or which encryption keys it intends to use. Something has to carry that opening message between them. That something is a signalling server, and every peer-to-peer system has one — ClearChat included.
The distinction that matters is what it carries. A signalling server passes a short technical description — a few kilobytes of text — and then has no further role. It never sees a video frame. A media server, by contrast, carries the call itself, for its entire length.
An app that says “peer to peer” while routing media through an SFU is not lying about having peers. It is hoping you don't ask which server the video goes through. It's worth asking. How WebRTC opens a call walks through exactly what the handshake contains.
Why most apps route media through servers anyway
There are honest reasons, and they're worth stating plainly:
- Group calls. Direct connections scale badly. Four people peer-to-peer means each device uploads three separate streams. At eight people it is unworkable on home broadband. An SFU means each device uploads once.
- Reliability. A server has a stable public address. Two home routers do not, and sometimes cannot be made to talk — see why a call won't connect.
- Features that need a copy. Recording, live transcription, cloud backgrounds and moderation all require the server to see the call.
- Mobile battery and data. One upload is cheaper than several.
None of these are conspiracies. They are the reason the industry settled where it did. But they all involve your call existing somewhere other than the two devices on it.
What going direct actually gets you
- No copy on anyone's server. Not “deleted after 30 days” — never written. A company cannot hand over, lose, or be compelled to produce something it never had.
- Lower latency. One hop instead of two, and no detour through a distant region. Two people in the same city stop routing through another continent.
- Encryption with no middle. When there is no server in the media path, there is nothing in the middle to trust. See is your call really end-to-end encrypted.
- It costs almost nothing to run. Which is why it can be free without advertising to you or selling anything about you.
What it costs you
Being straight about this matters more than the advantages:
- Two people, not ten. Direct connections don't scale to group calls.
- Both of you have to be there. There is no server holding a room open, so there is no ringing, no voicemail, and no “join early and wait”.
- You exchange IP addresses. To send packets to someone directly, you need their address, and they need yours. This is true of every peer-to-peer system.
- Some networks refuse. Certain combinations of routers cannot be made to connect directly at all. That failure is real and unfixable without a relay.
- Nothing is kept. No history, no recording, no transcript. If you wanted one, this is the wrong tool.
How to tell what you're actually using
In a Chromium browser, open chrome://webrtc-internals during a call and look at the
active candidate pair. A relay candidate means traffic is going through a TURN server. A
host or srflx pair on both ends means it is going direct.
A rougher test: call someone in the same building. If the delay is noticeably worse than a phone call, the packets are probably travelling a lot further than the room.
Where ClearChat sits
ClearChat is deliberately at the far end of this trade. One-to-one only. A signalling relay that passes the handshake and then drops out of the conversation. No media server, no recording, no account, and no group calls — not as a feature gap, but because adding them would mean adding the server that the rest of it exists to avoid.
That's a real trade, not a free win. If you need eight people and a recording, use something else. If you want two people and no copy anywhere, this is the shape that gets you it.