Unnamed videoconferencing SFU

(Unnamed SFU) is a videoconferencing server that is very easy to deploy (just copy a few files and run the binary) and that requires very moderate server resources. It is suitable for conferences (where a single speaker streams audio and video to hundreds or thousands of users), and for multi-party discussions (where a few dozen speakers stream audio and video to each other).

For small groups of people (up to 3 or 4), (unnamed) is preferred, since it provides better video quality, has a stronger security model, and requires minimal server resources.

Try it out

You are welcome to check out our test videoconferencing server.


Documentation is in the README. Try also ./sfu -help.


Get the source code by doing

git clone https://www.irif.fr/~jch/software/sfu.git
then check the included README.


Server features

The server is reasonably complete:

The following server features are planned but haven't been implemented yet:

I'm less sure about the following features:

Client features

The frontend is primitive but fairly usable; it has the following features:

If you don't like my frontend, it should be easy to roll your own. Human-readable outline. API documentation.

Server stability, resources and scalability

While still experimental, the SFU is being used in production in our department since early May 2020. We've been running meetings, small lectures, and student examinations. All issues found have been fixed.

The server has two properties that make me confident it will scale well:

Security model

Unlike (Unnamed), which encrypts all media end-to-end and treats the server as an untrusted channel, (Unnamed SFU) assumes that the server is trusted: all media is decrypted by the server and reencrypted before it is sent to the clients. This is, as far as I know, unavoidable with DTLS-SRTP, the security mechanism used by WebRTC.

On the other hand, since the client is not trusted, any bugs in the client code should not create security issues. Thus, it is reasonable to build user-friendly clients using the unscrutable Javascript frameworks that web developers tend to like.

Note however that I am neither a security specialist nor a competent system administator, and I may have gotten something wrong.