{"id":1361,"date":"2026-10-01T10:28:45","date_gmt":"2026-10-01T03:28:45","guid":{"rendered":"https:\/\/liveapi.com\/blog\/webrtc-sfu\/"},"modified":"2026-10-01T10:29:05","modified_gmt":"2026-10-01T03:29:05","slug":"webrtc-sfu","status":"publish","type":"post","link":"https:\/\/liveapi.com\/blog\/webrtc-sfu\/","title":{"rendered":"WebRTC SFU Explained: How Selective Forwarding Works, Architecture, and When to Use One"},"content":{"rendered":"Reading Time: <\/span> 13<\/span> minutes<\/span><\/span>

A two-person video call doesn’t need a server in the middle. A ten-person call does.<\/p>\n

Add a third participant to a peer-to-peer call and every browser starts encoding and uploading its video once per person on the call. By six or seven people, most laptops and home connections give up. A WebRTC SFU fixes that by having each participant upload one stream to a server, which forwards it to everyone else.<\/p>\n

Google Meet and Discord run on SFUs, and so do the open-source stacks most teams build on: LiveKit, mediasoup, Janus, and Jitsi.<\/p>\n

The short version: an SFU keeps each participant’s upload flat, costs you bandwidth instead of CPU, and stops being the right tool once most of your audience only watches.<\/p>\n

What Is a WebRTC SFU?<\/h2>\n

A WebRTC SFU (Selective Forwarding Unit) is a media server that receives audio and video streams from each participant and forwards selected copies of those streams to the other participants, without decoding or re-encoding the media.<\/strong> Each client uploads one stream (or a few simulcast layers) and downloads the streams it wants.<\/p>\n

The “selective” part matters. The SFU doesn’t blindly relay everything. It decides, per subscriber, which streams to send and at what quality, based on that subscriber’s bandwidth, screen layout, and who’s talking.<\/p>\n

The IETF calls this pattern a Selective Forwarding Middlebox in RFC 7667 on RTP topologies<\/a>, published in November 2015. The industry settled on “SFU.”<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Property<\/th>\nWebRTC SFU<\/th>\n<\/tr>\n<\/thead>\n
Full name<\/strong><\/td>\nSelective Forwarding Unit<\/td>\n<\/tr>\n
Role<\/strong><\/td>\nRoutes RTP media packets between participants<\/td>\n<\/tr>\n
Processes media?<\/strong><\/td>\nNo decoding or encoding; reads packet headers only<\/td>\n<\/tr>\n
Client upload<\/strong><\/td>\nOne stream (or 2\u20133 simulcast layers)<\/td>\n<\/tr>\n
Client download<\/strong><\/td>\nOne stream per visible participant<\/td>\n<\/tr>\n
Server cost driver<\/strong><\/td>\nBandwidth, not CPU<\/td>\n<\/tr>\n
Typical latency added<\/strong><\/td>\nTens of milliseconds<\/td>\n<\/tr>\n
Typical session size<\/strong><\/td>\n3 to a few hundred active participants per server<\/td>\n<\/tr>\n
Common open-source options<\/strong><\/td>\nLiveKit, mediasoup, Janus, Jitsi Videobridge, Pion-based servers<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

An SFU sits on top of the normal WebRTC<\/a> stack. Clients still use RTCPeerConnection<\/code>, ICE, DTLS, and SRTP. The difference is that the remote peer is a server, not another browser.<\/p>\n

WebRTC SFU vs MCU vs Mesh<\/h2>\n

There are three ways to connect more than two WebRTC participants. The choice decides your bandwidth bill, your server CPU bill, and how many people can join.<\/p>\n

Mesh (peer-to-peer)<\/h3>\n

In a mesh, every participant opens a direct peer connection to every other participant. No media server is involved, only a signaling server<\/a> to exchange SDP and ICE candidates.<\/p>\n

It’s the cheapest to run and the lowest latency. It also falls apart quickly, because each client encodes and uploads its video once per peer.<\/p>\n

MCU (Multipoint Control Unit)<\/h3>\n

A multipoint control unit decodes every incoming stream, composites them into a single video (a grid or speaker layout), re-encodes it, and sends each participant one stream.<\/p>\n

Clients do little work. The server does a lot: decoding and encoding video for every session is CPU-intensive, adds latency, and locks every viewer into the same layout.<\/p>\n

SFU (Selective Forwarding Unit)<\/h3>\n

An SFU splits the difference. Clients upload once like with an MCU, but the server only forwards packets like a router. Each client decodes several streams and lays them out however the app wants.<\/p>\n

Bandwidth math at 10 participants<\/h3>\n

Assume each camera stream is 1.5 Mbps and 10 people are on the call.<\/p>\n\n\n\n\n\n\n\n
Topology<\/th>\nUpload per client<\/th>\nDownload per client<\/th>\nEncodes per client<\/th>\nServer work<\/th>\n<\/tr>\n<\/thead>\n
Mesh<\/strong><\/td>\n13.5 Mbps (9 \u00d7 1.5)<\/td>\n13.5 Mbps<\/td>\n9<\/td>\nNone<\/td>\n<\/tr>\n
SFU<\/strong><\/td>\n1.5 Mbps (about 3.2 Mbps with 3 simulcast layers)<\/td>\n13.5 Mbps, or about 3.7 Mbps with 1 HD + 8 thumbnails<\/td>\n1<\/td>\nForwards 90 streams<\/td>\n<\/tr>\n
MCU<\/strong><\/td>\n1.5 Mbps<\/td>\n~2 Mbps (one composite)<\/td>\n1<\/td>\nDecodes 10, encodes 1\u201310<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Mesh breaks on upload first. Most residential connections can’t sustain 13.5 Mbps upstream, and a phone can’t run nine encoders without overheating.<\/p>\n

The SFU keeps upload flat no matter how many people join. Download grows with the number of visible participants, but simulcast lets the server send small thumbnails for everyone except the active speaker.<\/p>\n

The MCU wins on client bandwidth, but you pay for it in server CPU.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Criteria<\/th>\nMesh<\/th>\nSFU<\/th>\nMCU<\/th>\n<\/tr>\n<\/thead>\n
Practical size<\/strong><\/td>\n2\u20134<\/td>\n3 to hundreds (thousands with cascading)<\/td>\nLow tens per server<\/td>\n<\/tr>\n
Latency<\/strong><\/td>\nLowest<\/td>\nLow (adds ~10\u201350 ms)<\/td>\nHigher (decode + encode)<\/td>\n<\/tr>\n
Server CPU<\/strong><\/td>\nNone<\/td>\nLow<\/td>\nHigh<\/td>\n<\/tr>\n
Server bandwidth<\/strong><\/td>\nNone<\/td>\nHigh<\/td>\nMedium<\/td>\n<\/tr>\n
Layout control<\/strong><\/td>\nClient<\/td>\nClient<\/td>\nServer<\/td>\n<\/tr>\n
End-to-end encryption<\/strong><\/td>\nYes<\/td>\nYes (with Insertable Streams)<\/td>\nNo, server must decode<\/td>\n<\/tr>\n
Best for<\/strong><\/td>\n1:1 calls<\/td>\nGroup calls, webinars, interactive streams<\/td>\nLegacy SIP\/H.323 interop, weak clients<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Most production systems today use an SFU. Some add an MCU-style mixer just for recording or for dialing into phone systems.<\/p>\n

How a WebRTC SFU Works<\/h2>\n

A WebRTC SFU looks like a regular peer to each client. Here’s what happens when someone joins a room.<\/p>\n

    \n
  1. Signaling:<\/strong> The client connects to the SFU’s signaling endpoint (usually a WebSocket) and authenticates with a token.<\/li>\n
  2. Publish:<\/strong> The client creates an RTCPeerConnection<\/code>, adds its camera and microphone tracks, and sends an SDP offer to the SFU. The SFU answers.<\/li>\n
  3. Connectivity:<\/strong> ICE finds a path between the client and the server. Because the SFU has a public IP, this usually succeeds directly, with a TURN server<\/a> as fallback for restrictive networks.<\/li>\n
  4. Encryption:<\/strong> DTLS runs between the client and the SFU, producing SRTP keys. Media is encrypted on each hop: client to SFU, and SFU to each subscriber.<\/li>\n
  5. Forwarding:<\/strong> The SFU receives RTP packets, reads the headers (SSRC, sequence number, timestamp, header extensions), and copies each packet to every subscriber who wants that track. It rewrites sequence numbers and timestamps so each subscriber sees a clean stream.<\/li>\n
  6. Subscribe:<\/strong> When a new track is published, the SFU renegotiates with each subscriber and adds the track to their peer connection.<\/li>\n
  7. Feedback:<\/strong> Subscribers send RTCP reports (packet loss, NACKs, keyframe requests, bandwidth estimates). The SFU uses them to pick layers, retransmit lost packets, and ask publishers for new keyframes.<\/li>\n<\/ol>\n

    Steps 5 and 7 are where the “selective” happens. The server never decodes video, but it reads enough metadata to switch quality at the right frame boundary.<\/p>\n

    Publishers and subscribers<\/h3>\n

    SFUs model every participant as a publisher, a subscriber, or both. In a group meeting, everyone is both. In a webinar, two or three hosts publish and everyone else only subscribes.<\/p>\n

    Some SFUs use one peer connection per direction: one for publishing, one for subscribing. Others use a single peer connection with many transceivers.<\/p>\n

    Both work. Separate connections make renegotiation simpler; a single connection saves one ICE and DTLS handshake.<\/p>\n

    Simulcast and SVC: How an SFU Serves Different Networks<\/h2>\n

    An SFU can’t transcode, so it needs another way to send a 720p stream to a laptop on fiber and a 180p stream to a phone on 4G. That’s what simulcast and scalable video coding are for.<\/p>\n

    Simulcast<\/h3>\n

    With simulcast, the publisher encodes the same camera feed two or three times at different resolutions and bitrates, and sends all of them to the SFU. The SFU forwards whichever layer fits each subscriber.<\/p>\n

    Here’s how a browser publishes three simulcast layers to an SFU:<\/p>\n

    const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });\nconst pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });\n\nconst [videoTrack] = stream.getVideoTracks();\npc.addTransceiver(videoTrack, {\n  direction: 'sendonly',\n  sendEncodings: [\n    { rid: 'q', scaleResolutionDownBy: 4, maxBitrate: 150_000 },  \/\/ 180p thumbnail\n    { rid: 'h', scaleResolutionDownBy: 2, maxBitrate: 500_000 },  \/\/ 360p\n    { rid: 'f', maxBitrate: 2_500_000 }                           \/\/ 720p full\n  ]\n});\npc.addTrack(stream.getAudioTracks()[0], stream);\n\nconst offer = await pc.createOffer();\nawait pc.setLocalDescription(offer);\n\/\/ Send offer.sdp to the SFU over your signaling channel, then apply its answer\n<\/code><\/pre>\n
    The rid<\/code> values show up in the SDP<\/a> as a=rid<\/code> and a=simulcast<\/code> lines, defined in RFC 8853. The SFU uses them to tell the layers apart.<\/p>\n
    Simulcast costs the publisher extra upload (here about 3.15 Mbps instead of 2.5 Mbps) and extra CPU for three encoders. In exchange, the SFU can switch any subscriber between layers instantly.<\/p>\n
    Scalable Video Coding (SVC)<\/h3>\n
    Scalable video coding takes a different approach. The publisher sends one stream built in layers: a base layer plus enhancement layers for higher frame rate (temporal) or higher resolution (spatial). The SFU drops layers to lower the quality for a given subscriber.<\/p>\n
    SVC is supported in VP9<\/a> and AV1<\/a>. In Chrome, you request it with scalabilityMode<\/code>:<\/p>\n
    pc.addTransceiver(videoTrack, {\n  direction: 'sendonly',\n  sendEncodings: [{ scalabilityMode: 'L3T3' }]  \/\/ 3 spatial, 3 temporal layers\n});\n<\/code><\/pre>\n
    L1T3<\/code> is a common middle ground: one resolution with three temporal layers, so the SFU can drop from 30 fps to 15 or 7.5 fps for weak connections.<\/p>\n\n\n\n\n\n\n\n\n\n\n
    <\/th>\nSimulcast<\/th>\nSVC<\/th>\n<\/tr>\n<\/thead>\n
    Streams sent by publisher<\/strong><\/td>\n2\u20133 independent streams<\/td>\n1 layered stream<\/td>\n<\/tr>\n
    Upload overhead<\/strong><\/td>\n~25\u201340% more than a single stream<\/td>\n~10\u201320% more<\/td>\n<\/tr>\n
    Codecs<\/strong><\/td>\nVP8, H.264, VP9, AV1<\/td>\nVP9, AV1 (H.264 temporal only)<\/td>\n<\/tr>\n
    Layer switching<\/strong><\/td>\nNeeds a keyframe on the target layer<\/td>\nCan switch at layer boundaries<\/td>\n<\/tr>\n
    Browser support<\/strong><\/td>\nAll major browsers<\/td>\nChromium-based browsers; partial elsewhere<\/td>\n<\/tr>\n
    SFU complexity<\/strong><\/td>\nLower<\/td>\nHigher (must parse codec layer metadata)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Most SFUs default to VP8 simulcast because it works everywhere. Teams that control their clients often move to VP9 or AV1 SVC for the bandwidth savings.<\/p>\n
    Audio is simpler. Everyone sends one Opus<\/a> stream, and the SFU forwards only the loudest few speakers using the audio-level header extension, so a 50-person call doesn’t push 49 audio streams to every client.<\/p>\n
    Bandwidth Estimation and Congestion Control in an SFU<\/h2>\n
    Picking the right layer depends on knowing each subscriber’s downstream bandwidth. The SFU has to estimate it continuously.<\/p>\n
    There are two common methods:<\/p>\n