LiveKit SFU

Overview

LiveKit server is an open source WebRTC Selective Forwarding Unit (SFU) that routes media between participants. This topic compares the SFU model to peer-to-peer and Multipoint Conferencing Unit (MCU) architectures, and describes how LiveKit SFU is built.

Each of these architectures moves media, meaning audio and video, from publishers to subscribers. A publisher is a participant that sends media, and a subscriber is a participant that receives it.

Architecture comparison

A WebRTC app can send media directly between peers, or through a server that either mixes or forwards the streams. The choice determines how much bandwidth each participant uses, how much control your app has over individual tracks, and how far a session can scale.

Peer-to-peer

Plain WebRTC is a peer-to-peer protocol. When two peers connect, they exchange media directly. This works well for 2–3 peers. Beyond that, each peer has to upload a separate copy of its media to every other peer, and few internet connections can consistently upload five 720p video streams at 1.5 megabits per second each. Scaling WebRTC to groups of more than 2–3 people requires a client-server model.

Mixing with an MCU

An MCU, also known as a multipoint control unit, is a central server that combines the media from every publisher into a single stream for each subscriber. Each publisher sends its encoded and compressed streams to the MCU. The MCU decompresses and decodes each stream, combines it with the streams from other publishers, and sends one stream to each subscriber. It mixes audio streams together and composites video streams into a predefined layout, like a row or grid of tiles.

An MCU saves bandwidth on both ends. Each publisher sends only one copy of each stream, and each subscriber receives only one composite stream.

The tradeoff is flexibility. Your app can't adjust the volume of an individual audio stream, because the MCU has already mixed it. If your app UI doesn't use a row or grid of videos, you need to either compromise on the interface design or write code that splits the composite video back into individual tiles.

Scale is another limitation. Decoding, compositing, and re-encoding every stream requires a high-capacity server, and a session that grows too large for one server is difficult to split.

Forwarding with an SFU

LiveKit uses an SFU instead. An SFU is a router optimized for low-latency, high-bandwidth media forwarding. A publisher sends encoded and compressed media to the SFU, and the SFU forwards a copy of each stream to every interested subscriber without decoding or re-encoding the media. In WebRTC, each of these streams is called a track.

As with an MCU, each publisher sends only one copy of its media. An SFU trades downstream bandwidth for flexibility and scalability. A user subscribed to the camera feeds of five other participants receives five individual video streams, instead of the one composite stream an MCU sends.

In exchange, your app isn't tied to how the media server combines streams. You have full control over every individual audio and video track.

In a self-hosted deployment, each room must fit on a single node. LiveKit Cloud runs a globally distributed mesh of servers that supports rooms with unlimited participants.

LiveKit SFU also adapts tracks to each subscriber automatically. The server estimates the downstream bandwidth for each subscriber and forwards the quality layer, such as a lower resolution or bitrate, that fits within it. In client SDKs that support adaptive stream, you can also have the SDK request a resolution that matches the size of the video element and pause video that isn't visible.

LiveKit SFU architecture

LiveKit server is written in Go and uses Pion , a Go implementation of WebRTC. The SFU is horizontally scalable. You can run it on one node or a hundred nodes with an identical configuration.

A single-node deployment has no external dependencies. A distributed, multi-node deployment requires Redis. Redis records which node hosts each room and relays messages between nodes. This ensures that all clients joining a particular room connect to the same node.

The following diagram shows the LiveKit server architecture:

Additional resources

The following topics explain the concepts the SFU builds on and show you how to run your own LiveKit server.