How to know if an open source WebRTC media server is kept up to date?

If you are going to start a project that requires a WebRTC media server, you better be sure you know how frequently as well as when was the last time the code got updated.

A WebRTC media server is a type of server that is required to build applications that offer group calling capabilities among other things. There are other types of WebRTC servers that are needed, but this is not the place or time to discuss them.

Rising interest in updating media servers

Here’s a discussion I had multiple times in the last month: People asking about this or that WebRTC media server or project, wanting to know if they should adopt it for their own application.

This rise stems from the increased interest in video conferencing due to the pandemic. Video has shown its usefulness in the biggest possible way. We’re all stuck at home, and the only way to communicate is by “calling”. Video adds context and meaning to voice only calling so it is becoming widespread.

In some cases, as in India, the government decided to put out funding for a video conferencing challenge, where vendors are invited to build applications for the local market. In others, remote-something is becoming a thing where the existing generic solutions don’t cut it (there are many such verticals).

As it so happens, a lot of teams are now trying to figure out which open source WebRTC media server they should pick and use.

There’s an article I wrote almost 3 years ago on 10 Tips for Choosing the Right WebRTC Open Source Media Server Framework. I took the time today to update it as well as the selection worksheet in it.

One thing that developers seem to miss is how easy it is to understand the freshness of the code – how up to date a WebRTC media server code really is.

So here we go.

How do the most popular WebRTC media servers compare to each other?

What I like doing is using the insights feature in github. It gives a nice initial perspective of a project besides the popularity metrics of watches, starts and forks (they are nice, but just to get me interested – not it making an opinion).

For that purpose, I like looking at the Pulse, Contributors and Code frequency metrics provided by github.

Doing such a check is useless without context. And context is built by looking at alternatives. In this case,  I decided to look at some of the most popular WebRTC media server alternatives out there: Janus, Jitsi, Kurento and mediasoup

Why these 4? Because they are mentioned in almost every conversation I have about open source WebRTC media servers.

Some of these projects are built out of multiple github repositories. For the purpose of this comparison, I tried looking at the main repo holding the media server itself. Here’s the ones I’ve used for each:

• Janus: janus-gateway
• Jitsi: jitsi-videobridge
• Kurento: kurento-media-server
• mediasoup: mediasoup

Pulse

The github pulse lists recent activity of the project. I’ve looked at a period of 1 month here on all 4 projects to get the following picture:

A few thoughts:

• Jitsi and mediasoup seem to be doing a lot of code optimizations based on the ratio between additions and deletions
• Janus had a lot of additions versus deletions, so a lot of new code this past month?
• All projects are skewed towards a single developer at their core. Jitsi skewed towards two main developers
• Kurento is way behind the others
• mediasoup seem to have a smaller community of active contributors around it (it is the youngest of these projects)

Contributors

The github contributors view gives us a nice time perspective of these projects, with a focus on who are the main contributors over time.

A few thoughts:

• Activity in Janus has been stable over time, but leans heavily on a single developer, Lorenzo Miniero
• For Jitsi, activity is leaning on 3 developers, 2 of whom have been with the project for a very long time
• Kurento’s activity fell since the acquisition by Twilio and never really recuperated. Most activity since then can be attributed to Juan Navarro
• mediasoup’s activity has a kind of a cyclic nature to it that is hard to explain from outside. Most of the work there can be attributed to Iñaki Baz Castillo

Code Frequency

This chart on github shows the additions and deletions made to a project throughout its lifetime.

For the image below I tried aligning the projects as well as I could on the 10k  range, which might have distorted them a bit, but should place them nicely in the context of each other. Notice that I couldn’t do that for mediasoup – see my thoughts below. Also note that the X axis of the timescale in each is different, but that wasn’t interesting for me for this comparison.

A few thoughts:

• Janus and Jitsi show healthy code contributions throughout their existence. I attribute the spikes outside the chart area I’ve selected as on time efforts or just mistakes. Over time, they show stability
• Kurento’s activity has seen better days
• mediasoup is interesting. It shows bouts of activity, mainly due to heavy use of branching across its version releases
• These projects are rather small in nature. If you search github for popular projects outside the WebRTC space, you’ll see a lot higher levels of activity

Why do we want an up to date WebRTC media server?

This looks like an obvious question, but it really isn’t.

To check this out, lets look at another popular project that I suggest people to use when they need a SIP over Websocket implementation in JavaScript: JsSIP

Does this make JsSIP a dead project? Or is it just that there’s nothing much to add besides code fixes here and there?

(Interestingly, SIP.js shows totally different behavior)

When it comes to WebRTC, the same cannot be said. WebRTC is “work in progress” at its core. Browsers deprecate and introduce new features with each release, new codecs are introduced and the slew of use cases using WebRTC is still growing strong. This means that to keep pace with these changes, WebRTC media servers need to be updated as well. Otherwise, they wither and die, with time being unable to offer the level of quality and connectivity developers and users expect.

What other criteria should you be looking for?

Freshness of code is only one criteria, but there are many more. The first one should probably be does this media server fit my requirements? Not all media servers are built equal or for the same purpose, and deciding which one is most suitable is important as well.

Other criteria include usage, maintainability, support, documentation, etc.

You can find the full list in my article about it – 10 Tips for Choosing the Right WebRTC Open Source Media Server Framework

And if this is of real interest to you, then you should look at your selection process itself. For that, I can suggest my free media server selection KPI sheet.

Oh, and once you’re there, think about scaling as well. I have an existing eBook about best practices in scaling WebRTC applications, and an upcoming eBook on Optimizing Group Video Calling in WebRTC (available for pre-purchase).