What changes when you add an SFU (Mediasoup) in the middle of the pipeline?

Most WebRTC discussions about bitrate are wrong. Not because people don’t know the APIs, but because they don’t control the experiment.

So instead of asking:

“what bitrate should I use?”

I built something slightly different:

a reproducible WebRTC benchmark to measure how codecs behave under controlled conditions

This is what came out of it.

I’m happy to share that Mafalda SFU has been recognised as “Best Scalable Real-Time Media Platform 2026” at the Spanish Business Awards organised by EU Business News.

You can find the official listing at https://www.eubusinessnews.com/winners/mafalda-sfu/, and the announcement published on the project website.

It’s always nice when a side project receives some external recognition, especially one that started mostly as an experiment.

Google used to provide prebuild Android images of libWebRTC library, and in fact, it’s (still) the recomended way to use them on its own documentation. But starting on WebRTC M80 release (January 2020), they decided to deprecate the binary mobile libraries, and the reasons were that the builds were intended just only for development purposes, and users were already building it themselves with their own customizations, or using third party libraries that embedded them (where have been left developers that just want to build a WebRTC enabled mobile app?), and they just only provided another build in August 2020 (1.0.32006) to fill some important security holes, in case someone (everybody?) was still using the binary mobile libraries.

Also for the most basic use cases, WebRTC is a complex technology, with lots of moving parts and involved elements and parties working together at the same time, so when a WebRTC connection is not working properly, or directly it can not be created, there’s a series of not-so-obvious usual reasons that can make it fail. We are going to analize some of the most common ones, and when possible, see how we can fix them or find some alternatives solutions to minimize their impact.

Although Mafalda SFU is mainly focused on vertical scaling of Mediasoup and the WebRTC stack, the main problem I’ve found companies are facing is about how to easily implement Medisoup horizontal scaling. I’ve been working on a solution for this problem for a while on, and since Mafalda is build on top of Mediasoup, it’s also needed to help it to provide transparent vertical and horizontal scaling, so let’s see how it works.

When aproaching the horizontal scaling of WebRTC servers, we have two main aproachs: decentralized P2P, and using a central server. Each one has its own drawbacks and advantages, and I had difficulties to identify what aproach was the best, since I usually have a personal preference for pure P2P architectures, but they are not the most simple nor always the more efficient ones. So when deciding how to aproach Mafalda horizontal scaling, I needed to consider the pros and cons of each use case I would need, and here we have my conclusions.

Mafalda SFU is a massively vertical and horizontal scalable SFU built on top of Mediasoup. This allow to have (theorically) unlimited sized WebRTC-based video room calls.

When it comes to WebRTC architectures, there is no silver bullet. Depending on each use case, the optimal architecture may vary from project to another. For this reason, I am going to explain the main network architectures that are usually applied in projects based on WebRTC (and mainly applied to the streaming video), and what are the pros and cons of each one of them.

Respecto a arquitecturas WebRTC, no hay una bala de plata. Dependendiendo de cual sea el caso de uso, la arquitectura óptima puede variar de un proyecto a otro. Por este motivo, voy a explicar las principales arquitecturas de red que suelen aplicarse en proyectos basados en WebRTC (y principalmente aplicadas al streaming de video), y cuales son los pros y contras de cada uno de ellos.