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
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)
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
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.
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).
wouldn’t mind an analysis of intel’s Open WebRTC Toolkit https://software.intel.com/en-us/forums/intel-collaboration-suite-for-webrtc/topic/815043
You can apply the same techniques I did here on the github repository of the Intel stack.
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.
Thanks for the clarification Micael.
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.
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.
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.
True, which is why I’ve looked at a few other aspects as well.
Hey Tsahi, so interesting as always! Does the node based webRTC https://github.com/node-webrtc/node-webrtc project get left out for good reasons? If so could you share? Thank you!
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)
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
If what you need is SIP and you’re not interested in video, then this route makes sense.
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.