Slyber SFU Server is a standalone real-time video, audio, and data selective routing server written in Go on top of the Pion WebRTC v4 stack. This article explains in plain terms what problem the server solves, how packets move inside it, and how to choose the right operating mode for your application.
Why an SFU Server Is Needed and Why Direct Browser Connections Do Not Scale
When you make a direct browser-to-browser video call between two people, a point-to-point (Peer-to-Peer) topology is used. The first participant sends video to the second, and the second sends video to the first. The problem arises when five, ten, or fifty people join a room. With direct connections, each person's browser must encode and upload a separate copy of their video to every other meeting participant. If ten people are on a call, your smartphone or laptop simultaneously uploads nine heavy video streams to the network. This rapidly overheats the CPU, drains the battery, and completely saturates the uplink bandwidth.
The SFU (Selective Forwarding Unit) architecture solves this problem using a central switching node. Each participant sends their video and audio to Slyber SFU Server just once. The server receives these packets and instantly copies them to the other viewers in the room. At the same time, the server does not perform heavy video decoding or compositing on its CPU, allowing a single server node to simultaneously serve up to 5,000 active rooms with minimal latency.
Why the Server Only Needs a Single Network Port 4443
Traditional WebRTC servers open a separate random network port for each participant. Administrators have to open massive port ranges in firewall settings (such as 10000 to 60000), which complicates network configuration and container deployments in Docker.
Slyber SFU Server uses ICE-Lite mode along with built-in ICEUDPMux and ICETCPMux multiplexers. All media traffic across all rooms and participants flows through a single port 4443 over UDP and TCP. When a browser connects to the server, it sends a STUN binding check packet with a unique session username. The server records the client's network address and routes its encrypted media packets to the appropriate room. If a user is on a corporate network where UDP is blocked, the browser automatically falls back to TCP (RFC 4571) over the exact same port 4443. Control commands and telemetry use a separate HTTP and WebSocket port 8090.
How a Room Is Structured Inside the Server
To navigate the server API effortlessly, you only need to understand three core concepts of its internal engine:
- UpTrack (inbound publisher stream). When a participant turns on their camera or microphone, an
UpTrackobject is created inside the room. It ingests packets from the sender, stores recent video packets in a dedicated ring buffer in case of network packet loss, and distributes packets to all subscribed viewers. - DownTrack (outbound stream for a specific viewer). When another participant wants to watch that video, the server creates a dedicated
DownTrackchannel for them and attaches it to theUpTrack. EveryDownTrackoperates independently: it can forward full 1080p quality to a viewer on fast broadband while delivering a lightweight 270p stream to a viewer on a weak cellular connection. - SlyberPacket and zero-allocation memory management. To prevent garbage collection stalls when forwarding hundreds of thousands of packets per second, the server never allocates new heap objects per packet. All packets are acquired from a pre-allocated
sync.Poolmemory pool and returned immediately after transmission to viewers.
How the Server Adapts to Poor Network Conditions
Participants in a video call operate under vastly different network conditions—one may be on home fiber while another is riding the subway with a weak cellular signal. To keep video smooth for the second participant without freezing, Slyber SFU Server supports Simulcast and SVC technologies.
The sender's browser encodes the camera feed into three quality layers simultaneously: layer 0 provides a lightweight stream for weak networks, layer 1 delivers medium resolution, and layer 2 carries crisp high-definition video. Inside the server, the SubscriberBWE bandwidth estimation module continuously monitors each viewer's connection speed and packet loss. If a viewer's throughput drops, their personal DownTrack automatically switches to layer 0, preserving smooth audio and video. Detailed layer configuration is covered in Signaling Protocol and Quality Control.
Five Built-In Room Profiles for Different Products
The server supports five specialized room profiles that configure optimal router behavior out of the box:
- Profile
conference(group video conferences). Enables active speaker detection via RFC 6464 audio level headers and the Last-N bandwidth-saving policy. The server automatically pauses video feeds from silent participants and forwards video only from people who are actively speaking. - Profile
roulette_1v1(video roulettes and 1-on-1 chats). Limits active video to a single partner and activatesFastSwapRouletteTrackinstant switching. When clicking next partner, the server swaps the video source in fractions of a millisecond without SDP renegotiation or black screens. - Profile
broadcast(webinars and live streams). Optimized for ingesting streams from OBS Studio or a browser via WHIP and distributing them simultaneously to hundreds of viewers over WHEP and Simulcast layers. - Profile
gaming(ultra-low-latency streaming). Tunes retransmission buffers for minimal response time in interactive applications. - Profile
ai_voice(conversational AI voice dialogues). Activates integration with the/ai/wsgateway, allowing one or more AI voice bots to join a room over a standard WebSocket with human voice barge-in support.