Then I started exploring WebRTC properly. Not the copy-paste-a-tutorial kind. The actually understand what's happening kind.

That's where things got uncomfortable. That discomfort is exactly why I'm writing this.

The "just use sockets" trap

When I first thought about video calling, my brain went: peer A sends data, peer B receives it, put a server in between if needed. Like a chat app, but with video. How different could it be?

Very. Very different.

The first thing that breaks your mental model is that video/audio data isn't like your typical JSON payload. It's a stream. Continuous. Time-sensitive. Lossy by design — dropping a frame is acceptable, waiting for a retransmit is not. TCP isn't ideal here. Media is time-sensitive, so WebRTC prefers UDP because it's better to drop a frame than wait for a retransmission.

And once you're on UDP, you need something sitting on top of it to give you some structure. That's where RTP (Real-time Transport Protocol) comes in.

Before any media flows, peers still need a way to discover each other and exchange connection metadata. WebRTC intentionally leaves signaling undefined, which is why we often use WebSockets or Socket.IO for that part.

RTP — The thing nobody talks about enough

RTP is what actually carries your media. It's a protocol that runs over UDP and gives you:

• Sequence numbers (so you know packet order, even if they arrive out of order)

• Timestamps (for syncing audio and video)

• Payload type (so the receiver knows how to decode it)

Alongside RTP, there's RTCP — the control sibling. It sends feedback: packet loss stats, jitter, round-trip time. This is how the sender knows to back off quality or increase bitrate.

When I understood this, something clicked: WebRTC isn't magic. It's a stack. getUserMedia → encode → RTP → network → RTP → decode → render. Somewhere in that flow, you have to make architectural decisions. And those decisions are what makes or breaks your system at scale.

P2P — The "it just works" lie

WebRTC natively supports P2P (peer-to-peer). Two browsers, negotiate via SDP (Session Description Protocol), exchange ICE candidates, done. No server needed for media.

This is great for two people. And it genuinely works.

But the moment you have more than two peers in a call, P2P becomes a problem.

Say you have a 6-person call. In full mesh P2P:

• Every peer connects to every other peer

• That's 5 upload streams per person

• 6 people × 5 streams = 30 connections total

Your users are uploading 5 simultaneous video streams. On their home WiFi. While their OS is also doing background updates. You see the issue.

P2P mesh is a bandwidth and CPU nightmare at scale. There had to be a better way.

MCU — The old-school approach

MCU (Multipoint Control Unit) is the server-heavy solution. The server receives all streams, decodes them, mixes them into one combined stream, re-encodes it, and sends that single stream to everyone.

From the client's perspective: bliss. One upload stream, one download stream.

From the server's perspective: absolute carnage. Decoding and re-encoding video in real-time is computationally brutal. You're paying for that CPU hard. Also, the server now has access to the decoded media — which is a privacy consideration.

MCU made sense in the era of expensive codec hardware. In today's world, SFUs are often the preferred choice, unless you specifically need server-side mixing, broadcasting, or recording workflows.

SFU — The architecture that made things click

SFU (Selective Forwarding Unit) is the sweet spot.

The server receives streams from all participants, but doesn't decode or mix anything. It just forwards the RTP packets selectively to the right peers.

Every client still uploads once (to the SFU). But instead of receiving one mixed stream (MCU) or N-1 streams (P2P), they receive forwarded streams from the SFU — which can be optimized, filtered, and scaled intelligently.

This unlocks things like:

• Simulcast — send multiple quality layers, SFU picks the right one per receiver based on their bandwidth

• Selective forwarding — don't send the presenter's video to someone who has it minimized

• Recording — tap into the RTP stream server-side without decoding

The SFU doesn't touch your media. It just routes packets. This is both the efficiency win and the privacy win.

So why mediasoup?

When I started implementing an SFU myself, I hit a wall fast.

You're not just forwarding UDP packets. You have to:

• Handle WebRTC signaling (SDP, ICE)

• Manage DTLS handshakes

• Track SSRCs and stream lifecycles

• Handle simulcast layers

• Manage bitrate estimation and RTCP feedback loops

• Deal with NACK, PLI and FIR recovery mechanisms

At this point, you realize you're not building a feature anymore — you're implementing years of networking research.

mediasoup solves this. It's a Node.js library with a C++ core that handles all the low-level WebRTC/RTP machinery and exposes a clean API for routing, rooms, and transports. You focus on who talks to whom. It handles how the packets get there.

I didn't reach for mediasoup because it was the trending tool. I reached for it because I understood the problem it was solving — and that understanding only came after going deep enough to feel the pain.

mediasoup

The pattern I noticed

Every time I hit a new layer in this stack — RTP, RTCP, ICE, DTLS, simulcast — my instinct was to abstract it away. But each layer was there for a reason. The complexity isn't accidental.

P2P fails at scale → SFU fixes the topology problem SFU is hard to implement correctly → mediasoup handles the low-level correctly You still need to design rooms, routing, signaling → that's your job as the backend engineer

Understanding why a tool exists is a different thing from knowing how to use it. I'm glad I took the longer road here.

If you're building anything with real-time media and you're still at the "just WebRTC it" stage — go one level deeper. Understand RTP. Feel the P2P pain. Then look at your options.

The architecture will make a lot more sense.

-Adam