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

WebRTC is peer-to-peer by design, which leads many developers to assume they don't need any server infrastructure. That works for a simple call between two browsers. It breaks down once you deal with restrictive networks, group calls, or broadcasting to an audience.

What a WebRTC server does

"WebRTC server" really covers four separate jobs:

• Signaling: exchanging SDP offers, answers and ICE candidates so endpoints can agree on codecs, addresses and keys
• NAT traversal: STUN reports a device's public address; TURN relays media when a direct path fails, for example behind symmetric NAT or strict corporate firewalls
• Media routing: forwarding or mixing streams once there are more than two participants
• Fan-out: serving one publisher's stream to an audience the publisher can't connect to directly

A two-person call needs the first two. A broadcast to 10,000 viewers needs all four.

Do you need one?

Every WebRTC session needs signaling and STUN, even a two-person call. What else you need depends on the use case:

• 2 participants: signaling + STUN, plus TURN for sessions that fail direct connectivity
• 3–4 participants: same stack, and a mesh topology still holds up
• 5+ participants: add an SFU
• One-to-many broadcast: add an SFU and edge nodes

Mesh, MCU or SFU

• Mesh: every participant connects to every other. It works up to roughly four users and needs no media server.
• MCU: the server decodes and mixes all streams into one composite. Client bandwidth stays flat, but server CPU cost is high.
• SFU: the server forwards streams without re-encoding. It scales past 100 participants at moderate server cost.

The network topology guide covers the bandwidth maths in more depth.

Ingest: getting a stream to the server

A publisher can be a browser (getUserMedia), a hardware encoder, or OBS Studio. WHIP standardises WebRTC ingest into a single HTTP POST carrying the SDP offer, instead of custom signaling. The endpoint shape looks like this:

https://your-domain:5443/{application}/whip/{streamId}

Some servers also accept non-WebRTC sources such as SRT, RTSP and NDI. That lets a WebRTC audience watch a stream that never started as WebRTC.

Delivery latency matters more than ingest

Once a stream is on the server, the delivery protocol sets what viewers experience:

Protocol	Typical latency	Good for
WebRTC	~0.5 s	Auctions, betting, conversation, remote control
LL-HLS / LL-DASH	3–5 s	Large audiences needing near-real-time
HLS	8–10 s	Maximum device reach, one-way viewing

That's roughly a twenty-fold gap between the first and last rows. For many products it's the main architectural decision. For more on bridging real-time ingest to HTTP delivery, see WebRTC to HLS and DASH.

Comparing eight open-source servers

Eight projects cover most self-hosted deployments. Each optimises for a different goal:

Server	License	Language	Best fit
Ant Media Server	Apache-2.0 (CE) / commercial (EE)	Java	Broadcast and conferencing
LiveKit	Apache-2.0	Go	Conferencing and AI agents
mediasoup	ISC	C++ / Node.js API	SFU library with fine simulcast control
Janus	GPLv3	C	SIP/PBX bridging, modular gateway
Jitsi Videobridge	Apache-2.0	Kotlin / Java	Ready-made conferencing
Pion	MIT	Go	Building your own SFU from a library
MediaMTX	MIT	Go	Protocol relay (WebRTC, RTMP, SRT, RTSP)
Kurento	Apache-2.0	Java	Media processing pipelines

Two things narrow the shortlist quickly.

1. HTTP delivery. Five of the eight include no built-in HLS/DASH output. If you need real-time and large-audience playback together, you'll end up running a second system.

2. Licensing. Apache-2.0, MIT and ISC all allow closed-source products. GPLv3 (Janus) requires derivative works to carry the same license unless you buy a commercial one. Check this before the media layer is embedded in a shipped product.

Self-hosted vs managed API

The main trade-offs are cost shape and control:

• Self-hosted: flat cost as usage grows, and media stays inside your own infrastructure. That matters for regulated areas like telehealth or finance. You take on patching, scaling and monitoring.
• Managed API: no infrastructure to run, but fees scale with usage, and media passes through the vendor.

Hardware sizing

Capacity scales close to linearly with cores. Ant Media's published benchmark at 360p:

CPU cores	Broadcasts	Viewers	RAM
4	Up to 50	Up to 200	8 GB
8	Up to 100	Up to 400	16 GB
16	Up to 200	Up to 800	16 GB
32	Up to 400	Up to 2,000	16 GB

Past that, you scale by adding clustered nodes rather than cores. See the docs on clustering and scaling and Kubernetes.

Security basics

WebRTC encrypts media with DTLS-SRTP by default. For production, add HTTPS/WSS on the signaling channel, token-based publish and play authorisation (for example JWT stream tokens), and firewall rules that limit the media port range. See also the notes on WebRTC security.

Setting up a first stream

1. Provision a Linux host with 4 vCPUs, 8 GB RAM and SSD storage. Open port 5443 plus the UDP range used for media.
2. Install the server. The Community Edition builds are on GitHub. It ingests WebRTC but plays back over HLS at 8–12 s. WHIP, clustering and sub-second WebRTC playback are Enterprise features in Ant Media Server's case.
3. Publish a test stream, open the player on a second device and measure the delay. That's the only latency number that reflects your own network.

Full setup details are in the documentation, and questions go to the developer community.

Takeaway

Choose the server whose default architecture matches your workload. Adding broadcast behaviour to a conferencing-focused SFU later usually costs more engineering time than picking the right tool early.

Originally published at antmedia.io.