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
Documentation is in the README. Try also
Get the source code by doing
git clone https://www.irif.fr/~jch/software/sfu.git
then check the included README.
The server is reasonably complete:
- redistribution of arbitrary numbers of audio and video streams;
- recording to disk;
- NACK-based loss recovery, in both the client → server and
server → client directions;
- PLI-based repair;
- restarting of failed flows;
- congestion control in the server → client direction
(both loss-based and using REMB indications);
- congestion control in the client → server direction
(loss-based, partial REMB support);
- congestion control when the server is short on CPU;
- dynamic tuning of buffer sizes depending on the clients' RTT.
The following server features are planned but haven't been implemented
- a proper administrative interface (currently, administering the server
requires manually editing configuration files);
- complete REMB-based congestion control in the client → server
direction (more accurate reaction to congestion than the current loss-based
- simulcasting, the ability to have multiple streams at different
qualities and dynamically select which stream goes to which client based
on congestion indications (doing this right depends on having very
accurate congestion indications, so it's tricky);
- server federation (the ability to have one server in Europe, one
server in North America, and have only one flow cross the Atlantic).
I'm less sure about the following features:
- allowing peer-to-peer connections for small groups (essentially
integrating the functionality of (Unnamed) into
(Unnamed SFU); it's not clear that there's a way to do that without
confusing the users;
- transport-cc congestion control (it seems to me that it's equivalent
to REMB, just more chatty).
The frontend is primitive but fairly usable; it has the following features:
- basic text chat and videoconferencing;
- camera and microphone selection;
- screen and window sharing, including sharing multiple independent windows.
If you don't like my frontend, it should be easy to roll your own.
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:
- it is designed to scale linearly with the number of CPU cores (there
is minimal locking, and the data structures avoid false sharing);
- it is designed to degrade gracefully: when it detects that it is
getting backlogged, the server attempts to drop video packets while
preserving audio and control rather than lagging, disconnecting users,
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
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.