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 4 or 5), (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

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

Installation

Get the source code by doing

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

Features

Server features

The server is reasonably complete:

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

I'm not sure whether I know how to implement the following features:

Client features

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

Server resources and scalability

We ran a conference with 12 simultaneous speakers (12 upstream and 132 downstream flows, for both audio and video) on a $5 VPS (single core). 60% CPU with 120Mbit/s traffic, less than 200MB RAM occupation (mostly for the buffers used for NACK recovery).

The server is designed to scale linearly with the number of cores. Tests on a 4-core CPU indicate that this is the case with 4 cores; I don't have the hardware to test beyond that.

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.