Hey devs! 👋
In this overview, I will explain in simple terms what Slyber SFU Server is, why it is needed, how it works under the hood, and what problems it solves out of the box.

Slyber SFU Server is a real time selective audio, video, and data routing server written in Go. It is distributed as a single static binary with zero external dependencies and handles group video conferences, 1 on 1 calls, live streaming (for example, from OBS Studio), and voice conversations with AI agents. It can also be deployed via Docker.

Why Do You Need an SFU in the First Place?

When two people make a direct call in a browser, their devices exchange video and audio without intermediaries. However, as soon as 10 people join a room, peer to peer connections break down: each participant's browser is forced to compress and upload 9 separate copies of their video and audio one for every other participant. Phones quickly overheat, and batteries drain rapidly.

An SFU (Selective Forwarding Unit) acts like an automated mail sorting center:

1. You send a single video stream to the server.
2. The server does not decode or composite the picture on its CPU it simply copies the pre encoded packets and forwards them to the other participants in the room.
3. Because of this, a single server node can simultaneously handle up to 5,000 active rooms.

What Slyber SFU Server Can Do

I designed the server so that it can be deployed on a clean Linux machine in one minute without manually editing configuration files. Here is what the system consists of:

1. Single Port :4443 for Both UDP and TCP

In Slyber SFU Server, all media traffic across all rooms flows through a single port 4443. At the ingress, it uses ICEUDPMux and ICETCPMux multiplexers (RFC 4571 standard):

• If a user connects from home or a mobile network, traffic travels over UDP on port 4443.
• If a user is behind a corporate network where administrators have blocked UDP, the browser automatically falls back to TCP on the exact same port 4443.
• A separate 8090/TCP port handles WebSocket signaling (/ws), broadcast gateways, and telemetry metrics.

2. Adaptation to Poor Internet Connections

• A single call might include people on gigabit fiber alongside someone in an elevator with weak 3G. To keep video from freezing, the server supports multi stream Simulcast (q, h, f layers for example, 270p, 540p, and 1080p) and the scalable VP9 SVC codec.
• The built-in SubscriberBWE bandwidth controller continuously monitors reports from each viewer (TWCC, REMB, RTCP Receiver Report). As soon as a specific viewer's bandwidth drops or packet loss increases, the server smoothly switches only that viewer to a lighter layer without degrading video quality for everyone else.
• To prevent packet loss from flooding the sender with keyframe requests

3. Bandwidth Savings in Conferences

In a 30 person group call, there is no point in transmitting video from all 28 silent participants. The server reads the audio volume level from the unencrypted RFC 6464 (ssrc-audio-level) packet header without decrypting the voice payload itself. The EnforceLastNVideo mechanism automatically pauses cameras of silent participants and instantly resumes their video starting with a keyframe as soon as they begin speaking.

4. Sub Millisecond Peer Swapping in 1 on 1 Calls

In standard WebRTC, switching conversation partners requires re-exchanging SDP Offer/Answer messages, which leaves the viewer staring at a black screen for 1–2 seconds.

For the roulette_1v1 profile, Slyber SFU implements the FastSwapRouletteTrack method. Candidate streams are pre-warmed at ingress, and switching happens simply by flipping an internal pointer. The SeqTimestampRewriter module aligns packet sequence numbers (SequenceNumber) and timestamps of the new partner on the fly so the viewer's browser perceives the stream as continuous with zero gaps and zero SDP renegotiation.

5. Built In /ai/ws Gateway for AI Voice Agents

To add a voice bot powered by Gemini Live or the OpenAI Realtime API to a call, you do not need to run a heavy WebRTC stack in Python or Node.js. Simply connect your AI backend to the built-in /ai/ws WebSocket gateway:

• Multiplexing (mode=mux): Over a single WebSocket connection, you can run up to 6 independent bots with distinct voices in the same room each gets its own SSRC and separate audio track.
• 20 ms Pacer: Neural models output audio in uneven bursts; the server buffers them and releases frames into the room every 20 ms on the dot with accurate timestamp increments.
• Barge-In Interruption: As soon as a human starts speaking (3 consecutive voiced frames detected via the RFC 6464 header), the server immediately flushes the bot's unspoken audio queue and sends an ai_vad_barge_in event to your backend.

6. OBS Broadcasting (WHIP/WHEP), MoQ, and Server Cascading

• WHIP and WHEP: Stream directly from OBS Studio via POST /whip/{room}/{track} and distribute to viewers via POST /whep/{room}/{track} in a single HTTP request with ETag-based stream owner protection.
• MoQ Relay: Package media streams into moqt-draft-22 objects (/moq/{room}/{track}).
• Cascading (/cascade/): Link multiple Slyber SFU servers across different data centers over UDP with an HMAC-SHA256-128 cryptographic signature on every packet and built-in SSRF protection against attacks on local subnets.

7. Security and 3 Authentication Modes

• Flexible Authorization: Built-in verification of signed HS256 JWT tokens (with granular permissions like can_publish, can_subscribe, max_spatial_layer), a pooled Redis connection (instant access revocation upon deleting the slyber:session:<token> key), or stateless HMAC-SHA1 tokens.
• SFrame E2EE End-to-End Encryption: When REQUIRE_E2EE=true is enabled, the server validates RFC 9605 SFrame cryptographic headers and 16-byte GCM authentication tags, supports rotation of up to 16 MLS keys per SSRC, and blocks replay attacks using a 512-packet sliding window. The server cannot decrypt audio or video, routing spatial/temporal layers using the unencrypted RFC 9626 Frame Marking header extension.
• Memory & Rate Limiting: Incoming packets are processed through an atomic reference-counted sync.Pool without putting pressure on Go's garbage collector, while the TrafficPolice shaper enforces bitrate limits per track and per session.

Technical Specifications at a Glance

Quick Start

Install the server on a clean Linux host in one command the script downloads the binary, verifies the SHA256SUMS checksum, tunes kernel network buffers, generates secret keys in /opt/slyber_sfu/.env, opens port 4443, and starts the systemd service:

curl -fsSL [https://raw.githubusercontent.com/slyber-app/slyber-sfu-server/main/install.sh](https://raw.githubusercontent.com/slyber-app/slyber-sfu-server/main/install.sh) | sudo bash 

Or run it in Docker from the official GitHub Container Registry:

docker pull ghcr.io/slyber-app/slyber-sfu-server:latest docker rm -f slyber-sfu-server 2>/dev/null || true PUBLIC_IP=$(curl -fsSL4 --max-time 2 api.ipify.org 2>/dev/null || echo 127.0.0.1) JWT_SECRET=$(head -c 24 /dev/urandom | od -An -tx1 | tr -d ' \n') NODE_SECRET=$(head -c 24 /dev/urandom | od -An -tx1 | tr -d ' \n') docker run -d \ --name slyber-sfu-server \ --restart unless-stopped \ --network host \ -e SFU_ENV="production" \ -e PUBLIC_IP="${PUBLIC_IP}" \ -e SFU_UDP_PORT="4443" \ -e SFU_TCP_PORT="4443" \ -e SFU_HTTP_PORT="8090" \ -e AUTH_MODE="jwt" \ -e JWT_SECRET="${JWT_SECRET}" \ -e NODE_SECRET="${NODE_SECRET}" \ ghcr.io/slyber-app/slyber-sfu-server:latest && \ sleep 1 && \ docker exec slyber-sfu-server slyber_sfu doctor && \ echo "Public IP : ${PUBLIC_IP}" && \ echo "JWT Secret : ${JWT_SECRET}" && \ echo "Node Secret: ${NODE_SECRET}" && \ echo "Test Token : $(curl -fsS -H "X-Slyber-Node-Secret: ${NODE_SECRET}" "http://127.0.0.1:8090/auth/token?room=test-room&user=user-1")" 

Verify the health of a running node using the built in self
diagnostics command:

$ slyber-sfu doctor ================================================================ SLYBER SFU DOCTOR | Version: v1.0.0 | Node: slyber-sfu-01 ================================================================ [OK] Environment : production [OK] Public IP & Realm : 89.111.175.67 (slyber.com) [OK] Pion ICE Mux : UDP :4443 | TCP :4443 (ICE-TCP=true) | HTTP :8090 [OK] Auth & Security : jwt (E2EE=true, External TURN=1) [OK] All Slyber SFU self-diagnostics passed. ================================================================ 

Project & Documentation

GitHub Repository
Official Documentation
Technical Case Study