Why this matters
The Selective Forwarding Unit is the heart of any WebRTC product larger than a one-on-one call. You will live with this choice for the lifetime of the system: the language your team writes, the way you scale across regions, what kinds of recording you can offer, how telephony fits in, what AI-agent features you can ship next year. The wrong pick costs months of rewrites and a percentage of your monthly cloud bill that compounds forever. Most teams discover the constraints of their SFU only after deploying it. This article gives you the constraints before you choose.
What an SFU actually is, before we pick one
In a Selective Forwarding Unit, the server never decodes the media. Each participant uploads one encoded stream; the server inspects the packet headers, decides which subscribers want this packet, and forwards it untouched. The CPU cost on the server stays small because the heavy lifting — encode, decode, compose — happens on the clients. The result is the topology that scales: bandwidth is asymmetric and predictable, clients pay only for what they render, and rooms can grow from five to fifty without the server doing materially more work per stream. The previous article in this section, SFU vs MCU vs Mesh, walks through the three topologies side by side; here we go one level deeper and compare the five projects that actually implement the pattern in production.
Picking an SFU is rarely a question of "which one is best". The five projects below are all competent, all production-tested, all in active development. The question is which one matches your team, your roadmap, and the operational reality you can afford. The rest of this article is structured around that question.
Figure 1. Five SFUs at a glance. The internal architecture differs in language, process model, signalling layer, and what ships in the box. Pick by team strengths and roadmap, not by feature count.
mediasoup — the low-level engine
mediasoup is a WebRTC SFU implemented in C++ (the media path) and exposed as a Node.js library (the control path), with an ISC license. The project was started by Iñaki Baz Castillo in 2017 and is now backed by a small commercial sponsor pool. The architecture is unusual and is the source of both mediasoup's strengths and its sharpest edges: a Node.js process spawns one or more C++ subprocesses called workers. Each worker pins to a single CPU core. Inside each worker you create one or more routers. A router is the unit that holds a room — it holds the participants' producers (the streams flowing in) and consumers (the streams flowing out) and decides what each consumer receives.
Two consequences fall out of this design. First, mediasoup scales by process, not by thread: to use eight cores you launch eight workers, and your application has to decide which worker hosts which room. Second, mediasoup does not provide a signalling protocol. You write your own WebSocket layer, your own room manager, your own authentication. The library tells you what it can encode and decode; the rest of the product is yours to build.
mediasoup's official scalability documentation describes a single worker as comfortably hosting ~500 consumers in total — the consumer count is the right metric, not the participant count, because in a room of N people each participant has N − 1 consumers. So a worker that holds 500 consumers can host one ten-person room with 90 consumers, plus another ten-person room, plus a few smaller ones — or one larger room of 23 with 506 consumers, at which point you spread additional load across workers using pipeToRouter to interconnect them. Across workers on the same host, pipeToRouter keeps the media in shared memory; across hosts, the documentation describes the same pattern using a transport between routers.
Where mediasoup wins
The library is small, fast, and gives you almost total control of the media plane. The Node.js layer is enough JavaScript to keep a typical web team productive, while the C++ underneath stays out of the way until you want to read the source. Companies that ship video-heavy products with their own product UX and their own custom signalling — telemedicine systems with HIPAA-shaped requirements, e-learning platforms with bespoke breakout-room behaviour, conferencing tools that need fine-grained simulcast layer selection per consumer — choose mediasoup because the library does not impose a product on top of the engine. mediasoup is the engine; the product is your code.
Where mediasoup costs you
You write the signalling. You write the recording pipeline. You write the breakout-room logic, the moderator controls, the analytics export. The documentation is excellent but assumes you know what you want; there is no "start a server, get a meeting room" command. Time-to-first-call on a greenfield project is measured in weeks, not hours. Operationally, the multi-process model means your deployment has to keep workers alive, restart dead ones, and route signalling to the right worker for each room — work that LiveKit and Jitsi handle for you and that mediasoup leaves to your platform layer.
Production verticals where mediasoup is the right choice
Telemedicine builds where the product team needs to control every byte that touches a HIPAA-regulated session. Custom conferencing products where the UX, the recording format, and the integration with the rest of the SaaS matter more than out-of-the-box features. Education platforms with classroom-shaped sessions where the SFU is one piece of a larger application stack. In Fora Soft's video-streaming and e-learning practice, mediasoup is the engine we reach for when the customer is building a real product, not a meeting plugin.
Janus — the modular gateway
Janus is a general-purpose WebRTC server written in C by Meetecho. Where mediasoup is an engine, Janus is a gateway: a small core that handles the WebRTC plumbing (ICE, DTLS-SRTP, the JSEP offer/answer), and a set of plugins that turn the gateway into whatever application you want. Each plugin is its own shared object — janus_videoroom.so for SFU-style conferencing, janus_audiobridge.so for audio mixing, janus_streaming.so for RTSP and RTP ingest, janus_sip.so for SIP gateway functionality, janus_recordplay.so for stored sessions, and so on. Janus is GPLv3 licensed.
The plugin model is the architectural insight. You install the gateway once, enable the plugins you actually need, and your application talks to each plugin through a uniform HTTP/WebSocket/MQTT API. The same Janus instance can simultaneously serve as the SFU for a video call, the SIP bridge for a legacy phone integration, and the RTSP ingest endpoint for a surveillance camera feed. The combination is rare elsewhere — most other servers do one of those well and the others poorly or not at all.
The trade-off is configuration surface area. Janus has many knobs because Janus does many things. Production deployments typically tune the worker thread pool, the libsrtp/libnice versions, the per-plugin settings, and the systemd / coturn / nginx layout around the binary. The community is large and the documentation is detailed, but a first deployment without prior Janus experience takes longer than the equivalent on LiveKit or Jitsi Meet.
Where Janus wins
Janus is the strongest pick when you need to bridge worlds. If your product has to interoperate with SIP/PBX systems, ingest from RTSP cameras, expose a recording API, and host a multi-party video room — all from the same backend — Janus is the only project on this list that ships all of that as first-class plugins. The multistream branch (now the default) brought a unified SDP model that handles modern WebRTC's mid-based bundling cleanly. Meetecho, the company behind Janus, operates large WebRTC deployments themselves (including the WebRTC infrastructure for IETF meetings since 2014) and the project reflects that operational mileage.
Where Janus costs you
The plugin-per-use-case model trades flexibility for opinionated APIs. If the plugin's data model fits your product, you ship quickly; if it doesn't, you write a custom plugin in C, which is a different conversation than writing a custom signalling layer in Node.js for mediasoup. The C codebase is a barrier for teams whose first language is JavaScript or Go. And, like mediasoup, Janus does not give you a built-in horizontal-scaling story — you scale by running multiple Janus instances behind a load balancer and routing rooms to instances at the application layer.
Production verticals where Janus is the right choice
Surveillance products that need RTSP camera ingest plus WebRTC viewing. Telemedicine systems that include a SIP/PSTN leg for accessibility. Education and broadcast products with both live conferencing and recorded playback in the same backend. Any deployment where the SFU is one of several media-handling roles the server has to play. Fora Soft chooses Janus in video-surveillance and telemedicine projects whenever the same media server needs to handle RTSP, SIP, and WebRTC in one process.
LiveKit — the batteries-included platform
LiveKit, released in 2021 and licensed Apache 2.0, is the youngest project on this list and the one that ships the most out of the box. The core media server is written in Go and built on the Pion WebRTC library. Around the SFU, the LiveKit organisation ships an Ingress service (RTMP, WHIP, HLS, MP4 in), an Egress service (composite recording, individual track recording, RTMP out, HLS out), client SDKs for every major platform, server SDKs for half a dozen languages, and an Agents framework for AI participants. The combination has made LiveKit the default new pick for teams who want to be in production this quarter rather than next.
The architectural piece that distinguishes LiveKit from mediasoup or Janus is the distributed mesh. A LiveKit deployment is a cluster of identical nodes coordinated by Redis. Any participant can connect to any node; the cluster routes their media to whichever other nodes host the rest of the participants. A single room can therefore span multiple physical servers, and a single participant connects to the nearest node, minimising their last-mile latency. This is the same cascading-SFU idea that Jitsi shipped as Octo years earlier and that Boris Grozev described publicly in 2018; LiveKit's contribution is to package it as the default behaviour rather than an opt-in extension.
LiveKit Agents went 1.0 in April 2025 and reached Python 1.5 by April 2026, with adaptive interruption handling and native Model Context Protocol (MCP) tool support. An "agent" in LiveKit's framework is a participant like any other; the framework wires a speech-to-text input, an LLM, and a text-to-speech output to that participant's audio track. LiveKit Cloud, the managed offering, runs the same open-source code on the company's own infrastructure and adds the operational layer most teams would otherwise build themselves: global mesh, observability, SIP, agent deployment.
Where LiveKit wins
Time to product. A team that picks LiveKit can demo a working video application by the end of week one and a recorded session by the end of week two. The SDK story is broader and more polished than any other project on this list; the documentation reads like documentation for a product, not for an engine. For AI-agent products — voice copilots, customer-service bots, interview agents, real-time translators — LiveKit is the path with the least integration code.
Where LiveKit costs you
You inherit LiveKit's opinions. The data model, the room concept, the participant lifecycle, the SDK shapes — these are not configurable in the way mediasoup's are. If your product is video-conferencing-shaped, that is freedom; if it is not, the opinions become friction. The cluster model assumes Redis and a particular network topology; running LiveKit somewhere unusual (an air-gapped on-prem deployment, a country with restricted egress) is more work than running mediasoup in the same place. LiveKit Cloud has a usage-based price; LiveKit self-hosted is free, but you take on the operations of the cluster.
Production verticals where LiveKit is the right choice
Voice-AI products and copilots — the agents story is the largest single reason teams pick LiveKit in 2026. Conferencing products that want to ship fast and iterate on UX rather than on the media stack. SaaS products where the streaming engine is a means to an end and the team's energy should go into the product. Fora Soft uses LiveKit when the customer's primary value is product, not platform.
Jitsi Videobridge — the engine behind Jitsi Meet
Jitsi Videobridge (JVB) is the SFU at the centre of the Jitsi Meet conferencing platform. It is written in Kotlin and Java, licensed Apache 2.0, and developed by 8x8 since the company acquired Jitsi from BlueJimp in 2015. JVB is the longest-running open-source SFU on this list; the project's roots in Jitsi's earlier desktop client go back to 2003, and the SFU has been a production WebRTC component since 2014.
JVB does not stand alone. The full Jitsi Meet deployment includes Jicofo (the focus, which manages conferences and routes endpoints to bridges), Prosody (the XMPP server that carries Colibri2 signalling between Jicofo and JVB), the Jitsi Meet web client, and optional components for recording (Jibri), gateway services (Jigasi for SIP), and metrics. The architecture is opinionated and substantial — you do not run JVB on its own and write your own signalling against it the way you do with mediasoup. You run Jitsi Meet, and JVB is one of the services.
The cascading-bridge story (Octo, recently rebuilt as the relay protocol) is mature. JVB instances in different regions can be linked into a single conference, with Jicofo placing each participant on the nearest bridge. This is the architecture that lets the public Jitsi Meet deployment serve a global user base from a small number of regional bridges, and the same architecture is available in self-hosted deployments. Performance benchmarks published by the Jitsi team show a single JVB handling roughly 1,000 streams at ~1,500 MB resident memory — meaning one bridge can serve hundreds of small conferences or dozens of large ones, with linear scale-out beyond that.
Where JVB wins
If your goal is "a Jitsi Meet clone with our branding", JVB is the only choice that lets you ship by deploying the existing Jitsi Meet web client and pointing it at your bridges. The product UX is solid, the moderation tools are real, the recording (via Jibri) works, and the federation story with Octo is older and more battle-tested than any other project on this list. For internal-IT video conferencing — a corporate Zoom replacement, a campus meeting tool, a public-sector deployment — JVB plus the Jitsi Meet stack is a credible turnkey answer.
Where JVB costs you
The full stack is heavy. You operate Jicofo, Prosody, the bridges, optionally Jibri, optionally Jigasi, and the Jitsi Meet web client — five or six services in a single deployment. The JVM heap tuning, the XMPP server tuning, and the per-bridge configuration all become parts of your operational surface area. Customising the web client beyond branding requires forking it and maintaining the fork, which becomes a serious commitment over time. JVB is also less appealing if your product is not "meetings" — the data model and the client conventions assume a videoconferencing UX.
Production verticals where JVB is the right choice
Internal videoconferencing for organisations of any size. Government and public-sector deployments where data sovereignty rules out a cloud SaaS and the team wants a maintained reference stack rather than a build-your-own engine. Education platforms where the meeting room is the product. Telehealth deployments that want a turnkey clinical-meeting experience. Fora Soft considers Jitsi when the customer wants a finished conferencing experience to brand and host, not a media engine to build a product on top of.
Pion — the Go library, not the SFU
Pion is the WebRTC stack written in Go, licensed MIT and started by Sean DuBois in 2018. Pion is not an SFU. It is a complete Go implementation of the WebRTC protocols — RTCPeerConnection, ICE, DTLS, SRTP, the RTP stack, the data channel, the media engine — that you use as a library to build whatever WebRTC-shaped application you want, including SFUs. LiveKit's media server is built on Pion. ion-sfu is built on Pion. A long list of less-famous production WebRTC servers are built on Pion. If you write a WebRTC server in Go in 2026, you almost certainly start by importing Pion.
The reason Pion is on this list is that "build your own SFU on Pion" is a real and reasonable choice. For teams whose product needs are unusual — server-side audio processing baked into the SFU, codec routing logic that no off-the-shelf SFU implements, deep integration with another Go service stack, a deployment target that the other SFUs do not support — Pion gives you the protocol primitives without imposing a media-server shape. The Go toolchain is simpler than C++ or the JVM; the resulting binary is a single static file you can deploy anywhere.
Where Pion wins
You are a Go shop. Your product needs SFU semantics that no existing project ships and you have the engineering capacity to build them. You want the WebRTC plumbing handled by a maintained library without inheriting an opinionated server architecture on top. ion-sfu is the canonical example of "what an SFU built on Pion looks like" — small, focused, JSON-RPC signalling, transparent code — but the more common use is as a building block inside a larger product whose author needed to control every layer.
Where Pion costs you
Time to production. The number quoted by experienced Pion-based teams is twelve-plus months for a full SFU built on the library. You write your own load balancing, your own room model, your own recording, your own SDK story. The protocol primitives are excellent; everything above them is yours to build. For most teams, picking Pion is picking a language, not a product.
Production verticals where Pion is the right choice
Bespoke media products with unusual server-side requirements. Backend teams already standardised on Go that want WebRTC primitives without taking on Node.js or the JVM. Embedded and edge deployments where the single-binary deployment story matters and the LiveKit / Jitsi runtime is too heavy. Fora Soft has used Pion in projects where the customer needed custom server-side audio routing that no off-the-shelf SFU could express.
Figure 2. Decision tree for picking an SFU in 2026. Three honest questions — what is the product, what is the team's strength, what is the operational appetite — narrow the field to one answer most of the time.
The comparison matrix
The table below summarises the five projects across the dimensions that actually decide the choice in production. The "right answer" depends on which row matters most to your project — there is no single column that dominates the others.
| Criterion | mediasoup | Janus | LiveKit | Jitsi Videobridge | Pion |
|---|---|---|---|---|---|
| Language | C++ engine, Node.js control | C | Go (on Pion) | Kotlin / Java | Go (library) |
| License | ISC | GPLv3 | Apache 2.0 | Apache 2.0 | MIT |
| First release | 2017 | 2014 | 2021 | 2014 (as JVB) | 2018 |
| Ships SDK story | Server-side library only; you write client SDKs | Plugin-specific JS clients; community SDKs | Full first-party SDKs for web, iOS, Android, Flutter, React Native, Unity | First-party web client (Jitsi Meet); third-party SDKs | None — you build everything |
| Signalling | You write it | HTTP / WebSocket / MQTT to each plugin | First-party gRPC + WebSocket | Colibri2 over XMPP (Jicofo manages it) | You write it |
| Built-in cascading / multi-region | No (you implement with pipeToRouter) | No (app-layer) | Yes — Redis-coordinated mesh | Yes — Octo / relay protocol | No |
| Built-in recording | No | Yes (recordplay plugin) | Yes (Egress service) | Yes (Jibri service) | No |
| Built-in SIP gateway | No | Yes (sip plugin) | Yes (SIP service since 2025) | Yes (Jigasi) | No |
| Built-in AI-agent framework | No | No | Yes (Agents 1.5+) | No | No |
| Practical participant scale per node | ~500 consumers per worker (multi-worker per host) | Hundreds of participants per instance | Cluster-scaled — node count drives ceiling | ~1,000 streams per bridge | Whatever you build |
| Time to first working call | Weeks | Days to weeks (depending on plugin) | Hours | Hours (deploy the Jitsi Meet stack) | Months |
| Best when | You need an engine, not a product | You need RTSP/SIP/WebRTC in one server | You need to ship fast and want managed cloud as an option | You need a Jitsi-Meet-shaped product to brand | You need WebRTC primitives in Go |
A common mistake. Teams pick LiveKit because the docs are friendly, then later need to do something the LiveKit data model does not express, and rewrite. Or they pick mediasoup because someone recommended it, then spend three months building signalling and recording before showing a customer anything. Or they pick Jitsi because the demo looks impressive, then discover the web client they need to fork is a million lines of React. The honest first question is not "which SFU is best", it is what does our product need to be, and what is our team good at. Answer those first; the SFU follows.
A worked example: picking for three real product shapes
The decision tree compresses to one of three product shapes the vast majority of WebRTC builds fall into. The math here is for a 200-participant deployment with 50 concurrent rooms of 4 participants each — a realistic small-SaaS load.
Shape 1 — branded conferencing product, ship in 8 weeks. The customer wants a video product their users open in a browser. UX matters; protocol does not. The team is two backend engineers and one front-end. The right answer is LiveKit. Time to first call: hours. Time to first paying customer: 8 weeks. Server cost at 200 concurrent participants with simulcast: roughly $400–$800 a month on AWS, or the equivalent on the LiveKit Cloud usage plan. The team writes product code; the SFU stays out of the way.
Shape 2 — telemedicine platform with SIP bridge for accessibility and RTSP ingest for a clinical camera. Multiple media protocols converge in one backend, the regulatory environment requires self-hosting in a specific region, and the SFU is one of several roles the server plays. The right answer is Janus, with the videoroom, sip, and streaming plugins enabled in the same instance. Time to first call: a week. Time to production: 4–6 months. Server cost: a single beefy node handles the load at $300–$500 a month; the operational cost is the team's familiarity with Janus, not the AWS bill.
Shape 3 — bespoke conferencing system with proprietary signalling, custom recording format, and integration with an existing Node.js backend. The product team controls every byte; the SFU is the engine, not the product. The right answer is mediasoup. Time to first call: 2–3 weeks (you build signalling). Time to production: 6–9 months. Server cost: 8-worker host handles the load at $200–$400 a month; the engineering cost is the dominant line.
The model breaks if you pick a "shape 1" SFU for a "shape 3" product or vice versa. The cost of the mistake is not the server bill — it is the rewrite. Plan the product shape first.
Operational realities the marketing pages don't say
A few things every team learns in production, regardless of which SFU they pick.
Coturn is part of the deployment, no matter what. All five SFUs assume TURN relays exist for the percentage of clients (always 10–25%) whose NAT or firewall blocks direct UDP. You will run coturn (or an equivalent), you will pay for the bandwidth (TURN is bandwidth-expensive because it relays the full media stream), and you will tune it. None of the SFUs ship a TURN server.
Simulcast and SVC are not magic. All five SFUs support simulcast; some support VP9 SVC; LiveKit's recent versions support AV1 SVC. The benefit only materialises if your encoder is configured to produce the layers and your subscription policy is configured to pick the right one. The next article in this section, Simulcast and SVC: how the SFU serves a heterogeneous audience, covers the layer-selection logic.
Recording is its own product. "Recording" can mean composite output (a single mixed video file), per-participant tracks (one file per stream), or raw RTP capture. LiveKit's Egress and Jitsi's Jibri ship a composite-out story; Janus's recordplay plugin gives you per-participant; mediasoup and Pion leave it to you. Pick early — switching later means re-deriving everything from raw RTP.
Observability is not optional. Every SFU emits some form of stats. None of them emit them in a shape your dashboards will accept on day one. Plan to spend a few weeks wiring Prometheus, Grafana, and the per-client getStats() story into a coherent QoE pipeline. The Player observability and the metrics that ship in production article covers the metrics layer; the SFU side is similar.
The signalling layer is often where products fail. mediasoup and Pion leave it to you, and many teams underestimate the work. The signalling layer carries authentication, room membership, simulcast layer selection, breakout-room state, moderator commands, and the entire chat sidebar if you have one. Budget for it.
Where Fora Soft fits in
Fora Soft has been shipping WebRTC, conferencing, telemedicine, e-learning, and video-streaming products since the WebRTC standard was still draft. The five projects in this article are not abstractions for us — mediasoup is the engine inside several of our telemedicine and e-learning deployments; Janus is what we reach for when a surveillance or telemedicine project needs RTSP and SIP in the same server; LiveKit is the fastest path when a customer wants an AI-voice agent or a conferencing UX shipped this quarter; Jitsi Meet is the answer when the customer wants a turnkey conferencing platform to brand and host; Pion appears in projects with bespoke server-side audio routing or unusual deployment targets. The right SFU is the one that fits the customer's product, their team, and their operational appetite — not the one with the loudest documentation.
What to read next
- SFU vs MCU vs Mesh: the three WebRTC topologies — the topology choice that comes before the SFU choice.
- Simulcast and SVC: how the SFU serves a heterogeneous audience — what the chosen SFU actually does with multi-layer streams.
- WebRTC at scale: cascading SFUs, regional bridges, AI agents — the multi-region architecture that turns one SFU into a global service.
CTA
- Talk to a streaming engineer — book a 30-minute call with our WebRTC team.
- See our case studies — telemedicine, e-learning, conferencing, surveillance, OTT.
- Download the SFU selection cheat sheet — single-page PDF with the matrix and the decision tree from this article. Download (PDF).
References
- mediasoup official documentation — Overview and Scalability. Versatica. Accessed 2026-05-25. https://mediasoup.org/documentation/v3/ and https://mediasoup.org/documentation/v3/scalability/ — Tier 2 (reference implementation documentation). Defines worker/router architecture and the ~500-consumer-per-worker guidance used in this article.
- mediasoup-website source — RTP Parameters and Capabilities. Versatica (GitHub). Accessed 2026-05-25. https://mediasoup.org/documentation/v3/mediasoup/rtp-parameters-and-capabilities/ — Tier 2. Source for the router-level codec capability model.
- Janus WebRTC Server — official documentation and plugin index. Meetecho. Accessed 2026-05-25. https://janus.conf.meetecho.com/docs/ — Tier 2 (canonical project docs). Source for the plugin-per-use-case model, multistream branch status, and the
videoroom/sip/streaming/recordplayplugin inventory. - "Janus: a general purpose WebRTC gateway" — Amirante, Castaldi, Miniero, Romano (ACM IPTComm 2014). https://dl.acm.org/doi/10.1145/2670386.2670389 — Tier 5 (peer-reviewed academic publication by the project's authors). Origin paper for the Janus architecture.
- LiveKit Server — repository and documentation. LiveKit Inc. Accessed 2026-05-25. https://github.com/livekit/livekit and https://docs.livekit.io/ — Tier 2. License (Apache 2.0), Go-on-Pion implementation, distributed-mesh architecture.
- "How we built a globally distributed mesh network to scale WebRTC" — David Zhao (LiveKit), 2023. https://blog.livekit.io/scaling-webrtc-with-distributed-mesh/ — Tier 3 (engineering blog from project maintainer). Source for the multi-home session model.
- LiveKit Agents framework documentation. LiveKit Inc. Accessed 2026-05-25. https://docs.livekit.io/agents/ — Tier 2. AgentSession primitive, 1.0 (April 2025) and 1.5 (April 2026) release timeline, MCP tool support.
- Jitsi Videobridge — repository and Colibri2 docs. 8x8 / Jitsi project. Accessed 2026-05-25. https://github.com/jitsi/jitsi-videobridge and https://github.com/jitsi/jitsi-videobridge/blob/master/doc/relay.md — Tier 2. Kotlin/Java implementation, Octo/relay cascading, Colibri2 over XMPP.
- "Jitsi Videobridge Performance Evaluation" — Jitsi project, performance testing report. https://jitsi.org/jitsi-videobridge-performance-evaluation/ — Tier 3. Source for the ~1,000-stream and ~1,500 MB RSS figures referenced in the article.
- "Improving Scale and Media Quality with Cascading SFUs" — Boris Grozev (webrtcHacks, 2018). https://webrtchacks.com/sfu-cascading/ — Tier 3. The original Jitsi Octo writeup that established the cascading-SFU pattern other projects later adopted.
- Pion — repository and project site. Sean DuBois et al. Accessed 2026-05-25. https://github.com/pion and https://pion.ly/ — Tier 2. MIT license, Go WebRTC stack, used as the foundation of LiveKit and ion-sfu.
- ion-sfu — Pure Go WebRTC SFU. Accessed 2026-05-25. https://github.com/ionorg/ion-sfu — Tier 2. Reference example of a Pion-based SFU.
- "Comparative Study of WebRTC Open Source SFUs for Video Conferencing" — André, Le Breton, Lemesle, Roux, Gouaillard (CoSMo, IPTComm 2018). https://mediasoup.org/resources/CoSMo_ComparativeStudyOfWebrtcOpenSourceSfusForVideoConferencing.pdf — Tier 5. The CoSMo load-test benchmark referenced for cross-SFU performance context.
- RFC 8825 — Overview: Real-Time Protocols for Browser-Based Applications. IETF, May 2021. https://www.rfc-editor.org/rfc/rfc8825 — Tier 1. WebRTC architecture document that defines the browser-side protocol all five SFUs implement.
