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

May 18, 2020

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.

Open Source

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.

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:


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:

Total commits7635842

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)


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).

You may also like


Your email address will not be published. Required fields are marked

  1. Thank you for the comparison Tsahi,

    It is fair to say that Kurento is only maintained by Juan Navarro. I just want to point out that the rest of the team is working hard on OpenVidu “signaling server”.

    Some time ago we decided to have two projects with different names to allow users to differentiate between “low level” (Kurento Media Server) and “high level” (OpenVidu).

    I know it is very hard to compare and that you have done your best for a fair comparison. And I think also that other media servers are really good products in the state of the art of WebRTC.

  2. Not that it would change the stats at all, but it should be noted that Kurento Media Server is split across multiple repos in a bit of an extreme way: the repo “kurento-media-server” is literally just the server part, this is, a JSON-RPC WebSocket server that starts as a daemon, loads plugins at runtime, and awaits for client connections. Nothing else. No trace of WebRTC at all in this repo.

    Just to provide an overview of other repos:

    * kms-core and kms-elements are the most important plugins loaded by the server: they contain the whole RTP and WebRTC stacks. If anything, a future activity analysis should cover these two. No new big features are being added though, not even simulcast, as for the most part Kurento users have been vocal about preferring a rock solid WebRTC server even if it means not having the newest stuff from the WebRTC world. So these features are considered “done”, and we’re 101% focused on improvements to stability and reliability.

    * kms-filter is another plugin that comes with some niceties just for demonstration purposes, such as OpenCV filters.

    * kurento-java contains the Java SDK and the whole Kurento Test Framework that is used to write dozens of automated Integration tests for our CI infra (including automatic deployment of Dockerized browsers in order to perform fully end-to-end testing).

    * Finally there are other repos around there such as those with tutorials, or doc-kurento, which contains the comprehensive ReadTheDocs contents and is constantly updated.

    1. Thanks for the clarification Juan. I am assuming the kms-core and/or kms-elements would have been the part where people should focus their minds when looking for insights then – especially when it comes to supporting the WebRTC components.

  3. Hi Tsahi, nice comparison 🙂

    Regarding the number of contributors – I think it can be misleading, as it possible that some of them are using their own branches and one guy is only doing the merges to the master branch.

    1. Michael,

      Two reasons:
      1. Never bumped into someone using it directly
      2. It looks like a WebRTC client running on node.js and not a WebRTC media server (there’s a distinction between the two)

  4. It will be correct to KAMAILIO and OPENSIPS as signalling servers for the Websocket based SIP clients (like JsSIP, as mentioned in the topic ) and also add RTPENGINE project and CoTURN as media relay servers.
    RTPENGINE acts really well as TURN and even more:
    – it has awesome integration with KAMAILIO and OPENSIPS
    – it has really simple API and can be integrated with other services as media server

    The only con that it does not support RTP over TCP yet, but it perfectly runs with coTURN as TCP to UDP gateway as both of them support ICE proto

  5. Hey,
    This is a nice comparison.

    I needed a comparison between mediasoup and Janus. I liked the modularity of Janus and was leaning towards that.

    This article surely helped.


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}