WebRTC Servers Explained: Signaling, TURN, SFUs and How to Set One Up

WebRTC is a peer-to-peer technology by design, but developers often assume they don't need server infrastructure. This assumption breaks down when dealing with restrictive networks, group calls, or broadcasting to an audience. A WebRTC server fulfills four main roles: signaling, NAT traversal (STUN/TURN), media routing, and fan-out.

Signaling exchanges SDP offers, answers, and ICE candidates to agree on codecs, addresses, and keys. NAT traversal handles reporting a device's public address and relaying media when a direct path fails. Media routing forwards or mixes streams once there are more than two participants. Fan-out serves one publisher's stream to an audience the publisher can't connect to directly.

A two-person call requires only signaling and STUN, while a broadcast to 10,000 viewers needs all four components. For 2 participants, signaling + STUN is sufficient, with TURN needed for sessions that fail direct connectivity. For 3-4 participants, the same stack works, and a mesh topology can still be used. For 5+ participants, adding an SFU is necessary.

A one-to-many broadcast requires adding an SFU and edge nodes. A mesh topology connects every participant to every other, working up to roughly four users without needing a media server. MCU (Multi-Point Control Unit) decodes and mixes all streams into one composite, keeping client bandwidth flat but increasing server CPU cost. Mesh, MCU, and SFU each have different scaling requirements and costs based on the number of participants.

Ingest involves getting a stream to the server, with publishers being browsers, hardware encoders, or software tools like OBS Studio. Some servers accept non-WebRTC sources like SRT, RTSP, and NDI, allowing WebRTC audiences to watch streams that never started as WebRTC. Delivery latency matters more than ingest, with protocols like LL-HLS/LL-DASH offering sub-second latency for real-time applications like auctions, betting, or remote control.

Eight open-source servers provide most self-hosted deployments, each optimizing for different goals such as broadcast and conferencing, API SFU library, SIP/PBX bridging, or ready-made conferencing. When choosing a server, consider the default architecture's match to your workload. Adding broadcast behavior to a conferencing-focused SFU later typically costs more engineering time than selecting the right tool initially.