SFU
Also written Selective Forwarding Unit, Selective Forwarding Middlebox, SFM
A server that terminates each participant transport and forwards selected RTP streams onward without decoding them.
A mesh of peer connections falls over at about five participants, because every sender uploads a copy per viewer. A mixer scales but has to decode and re-encode everything, which costs a lot of CPU and adds a frame or two of delay. An SFU sits between the two: it terminates the transport with each participant and relays packets, but never decodes the media.
That makes it cheap enough to run thousands of participants per box, and it pairs naturally with simulcast, since choosing which layer to forward is a routing decision rather than an encoding one.
Three consequences worth knowing. The SFU terminates DTLS, so it can read every stream, which is why end-to-end encryption needs a separate layer. It is usually an ICE lite agent, so your client is the only side running the full ICE state machine and the only side that can move the connection to a new path. And it becomes the funnel for every keyframe request in the room, which it has to rate limit or the sender will drown.
RFC 7667 calls it a Selective Forwarding Middlebox. Everyone else says SFU.
Read more
- Fast WebRTC reconnection without a full ICE restartWhen a phone moves from Wi-Fi to cellular, an ICE restart costs a full offer/answer. Against your own SFU there are faster ways to move the call.
- WebRTC E2EE with SFrame: what your SFU can still readSFrame hides WebRTC media from the SFU, not the metadata. Your server still sees who spoke, when and how loudly, from the audio level header extension.
- Why WebRTC video freezes, and how getStats tells youWebRTC video freezes come from loss, keyframe waits, jitter or dropped frames. The getStats counters that tell them apart, and the fix for each.