Aller au contenu principal

SFU WebRTC: Selective Forwarding for enterprise video

Short answer

An SFU (Selective Forwarding Unit) is a WebRTC server that receives each participant’s stream and forwards it selectively to others without transcoding. It keeps low latency, limits client CPU load, and scales multi-party meetings—the standard model for professional video infrastructure.

How does an SFU session work?

  1. Signaling (HTTPS/WSS): room creation, SDP exchange;
  2. ICE / STUN / TURN: network path to the SFU;
  3. Publish: each participant sends audio/video/screen to the SFU;
  4. Selective forward: SFU routes relevant streams per receiver;
  5. Adaptation: simulcast/SVC adjusts quality to bandwidth.

SFU vs MCU vs P2P

P2P SFU MCU
Model Direct client links Selective relay Mixed composite stream
Transcoding No No Yes
Latency Lowest (1:1) Low Often higher
Scale ~2–3 participants Dozens to hundreds+ Variable, costly
Modern pro usage Short 1:1 Standard Legacy / hardware rooms

Why SFU is central for scalability

  • Horizontal scaling: SFU node cluster behind a load balancer, with session pinning (one SFU per session);
  • Simulcast: client encodes multiple qualities; SFU sends the one suited to each receiver;
  • SVC (Scalable Video Coding): dependent video layers (VP9, AV1) for fine adaptation without retranscoding;
  • Selective forwarding: speaker detection, dynamic layout, reduction of unnecessary streams;
  • Low latency: no intermediate transcoding pipeline.

Sizing strategies, associated TURN capacity and cluster approaches are detailed on scalable WebRTC infrastructure.

Where to host the SFU

The SFU processes real-time media streams: a critical component for sovereignty and compliance.

Model Use case Watch point
France / EU cloud Standard deployment, EU data residency Verify actual SFU node location, not just the web portal
On-premise Regulated sectors, strict IT policies Plan hardware sizing and redundancy
Hybrid Internal staff + external guests Internal SFU + TURN relay for blocked connections

See France hosting and sovereign video cloud.

Symptoms of an undersized SFU

Symptom Likely cause
Stable at 5, unstable at 20 Insufficient SFU or bandwidth
Latency rises with participants SFU node CPU or network saturation
Quality degraded for everyone No simulcast / SVC
Random disconnections ICE timeouts, no backup TURN
OK in pilot, degraded in production Real load not simulated, cluster not sized

A real network pilot (corporate workstation + 4G + screen share) remains the best test before general rollout.

FAQ

When is an SFU required?

From 3+ participants in real-time interaction, P2P becomes unsustainable; SFU is the expected architecture.

Does SFU work on corporate networks?

Yes with documented STUN/TURN and firewall rules—part of enterprise rollout.

How does SFU relate to the video API?

The SFU is the media plane; video API and signaling are the control plane for your applications.

Key takeaways

  • SFU is the distribution layer of professional WebRTC—not a replacement for WebRTC standards.
  • Prefer SFU over MCU for scalable browser-based meetings.
  • Size STUN/TURN and SFU capacity with your IT team before production rollout.

Next step

Request a quote to scope SFU capacity, TURN, and sovereign hosting.