My attending W3C TPAC in Lisbon, portugal, this week signs the end of my european webrtc teams tour. This post will be the first one reflecting the meetings I had. Janus has always been an interesting project. Technically, the fact that it is written in C and very small makes it one of the best server for IoT (kurento or jitsi would be less suited). Its plug-in/extention architecture,  not only keep it even leaner, but also allows to very easily build different types of media server (MCU, SFU, …) or app server (SIP Gateway, …). The IETF leveraging them to replace webex for their meetings (thousands of attendees each) and slack for their infrastructure, not only validated their product but also the market, and business viability. The danger of course is to be ONLY influenced by what I read, or people I consult for, which admittedly is too small a subset to draw any reasonable conclusion from. So I decided to hear from them.

[the latest global presentation of Janus can be found here]

I. The Genesys

Routed in Scientific Excellence and Academic R&D

Originally, the team was working on Real Time Media on the web. It was early days, it was a Java plugin, it was painful. WebRTC came along and things became much simpler.

They started by evaluating the web conferencing use case only, and then extended to multimedia in general. Born at the edge, they stayed at the edge and continued academic research and standards participation. If you want to improve, train with the best.

If you want to be the best, compete with the best and win. It was time to create a company and to test viability of the technology and the product.

Company creation and status

Meetecho was created in 2009, as an academic spin off of the University of Napoli Federico II.

Unlike american Spin Offs, the company is not attached with the university or share anything with it anymore. Most of the team graduated from there and Simon Pietro is still active as a Professor at the university, but most are “knee deep” in the company. Most importantly, the university does not own any IP, and the company is also today free of  external investment, with total control over its equity.

The business model

The main activity today is consulting around the open source technology portfolio. This is quite an usual business mode in Europe, and not very different from what all other open source project do (including jitsi, and kurento). Interesting enough, the amount of local consulting is close to zero. It is a global play.

The second biggest activity is actually Event streaming (or remote access) management. Starting from the technical ecosystem in which they were participating like IETF, ACM, ….. this activity is growing. The IETF for example is slowly replacing their system based on static MP3 stream for audio, webex for session sharing, downloadable slides and jabber for chat, by a Janus-based solution which integrates all of the above and video within a single app. More detailed information, even if slightly outdated, can be found on that 2014 article in the IETF journal. This was not a paid activity at first, more an experiment. For comparison sake, it took 3 years to grow into a revenue generator vertical.

Eventually, they also provide non open source products, but that would only contribute marginally to the revenues.

Who is Using Janus (show me the money~~!)?

Not everybody who use Janus make it public, nor has a commercial license since it’s an open source project. However, many do, and some go back to Janus for help in extending its feature, installation, architecture or maintenance. Here is a small list of some meetecho users:

• jangout (hangout clone)
• sylkserver.com
• lenovo’s airclass
• sqwiggle.com / speak.io
• veeting room (and they do show their love)
• alicex.com
• slack
• beam (acquired by Microsoft)

II. The Technology, products and services.

nomenclatura

What is interesting is that in the webrtc media server ecosystem, a large number of names are used to refer to a media server, depending on the use case, the architecture and the point of view. Gateway, Application Server, Conference Server, MCU, SFU, video bridge, video router, webrtc server, ….

Janus originally referred to Janus as a webRTC gateway, and explained why in at least one post on webrtchacks. The post is worth reading, however long, as it explains a lot of the basis of a webrtc media servers in general, beyond Janus.

Nowadays, they realized that this wording can confused their audience and are thinking about how to better present what the Janus server do. In their view, a webRTC Server should be both on the signalling and media path, which are then coupled, where some other media server would stay only on the media path (with potentially a specific channel to speak with a signaling server, like the colibri language used by jitsi video bridge).

Use cases.

There are many ways to look at use cases, and that’s what makes the comparison between media servers so hard. In the webrtc to SIP (a.k.a. SIP gateway) use case, depending on the expected features and type of calls, you can end up with very different cases (from trivial to hard):

• audio, 1-1.
  The easiest, even if you still have encryption mismatch.
• audio, 1-many.
  RTCP/RTP packets needs to be duplicated and sent to many receiving peers. You also get multiple RTCP feedback that can influence one another (a remote peer on a bad network would decrease the quality of all connection if handled naively).
• video 1-1.
  Main problem: no common video codec. You need to transcode and mix the audio, that is CPU intensive.
• Video multiparty.
  It becomes more problematic the more people you add to the conference. If you pass a certain threshold (the maximum number of streams a single server can support) you start having challenging infrastructure problems.

Another way to look at it is the overall use case for the media server.

– web conferencing
– real time multimedia streaming and processing
– (non-real-time) Streaming / Broadcasting
– router / SFU
– SIP gateway

What is interesting is that Janus allow you to implement all of the above, or combinations of the above, thanks to its plugin/extention mechanism. Not only can you do it all, but you only use what you need, as opposed to more monolithic approaches where all the features are entangled, and you pay for it (if only in memory footprint and maintenance, and even possibly in CPU footprint) even if you do use them. Kurento is a very capable media server which would be more monolithic for example.

III. Deeper view into Janus architecture

Original Publication: “Janus: a general purpose WebRTC gateway”, in the Proceedings of the Conference on Principles, Systems and Applications of IP Telecommunications.

What they have today

• generic architecture, reusable and expandable depending on use case.
• core: webrtc stack (acts as UA)
• Transport plugins.

• plugin for processing (application logic)
  • Media Plugins 
    • RTMP/silverlight support
    • SIP/SDP/RTP
    • RTSP/RTP

    ex: echo

  • ex: Streaming
  • ex: Video Room (SFU)
  • ex: SIP Gateway
  • ex: audio bridge
  • note: cannot chain two plugins, all plugins connects the core to the app with possibly additional processing involved.

Helpers and Administration

• query server API
• enable / disable some things dynamically.
• Inspects handles and internals (stats …)
• Jattack <=> puppet master / load testing (native stack) (IPTComm paper)

What is interesting is that we start seeing tools and additional plugin emerging from the community, which means the community has reached the critical mass.

What’s next?

• async coming (between core and logic plugins)
• large scale streaming (PhD subject of the lead)
• PaaS (dockerize the techno, nice front-end)
• Renegotiation
• more than 1 stream of 1 type per PC

What about SVC codecs? Well, Janus team feel like they are not experts of codecs, so do not want to lead on this, but will be very happy to use it when it will be available in the webrtc stack and/or libvpx/webm. 

Self Comparison with the usual suspects

• kurento?
• meedoze?
• licode?
• media soup?

“We know what they do, the use cases they address, but not so much the internals and the implications. Thanks for the plugin architecture, we address many use cases, while staying lean. We have not made specific benchmarks, as each use case would require its own benchmark, but we see most of them as addressing only one or two use cases, moreover we do not dare make specific comparisons to other tools.”

“While we know our own code as our pockets, and so are very well aware of our strengths and weaknesses, that’s absolutely not the case for the other tools out there, some of which we have never even installed/used. As such, we only know in general what they’re advertising, what use case they’ve been conceived for, but can’t possibly compare the performance, for instance, and it would be unfair of us to say we’re better/worse than other things out there. That’s why every time we’re asked “how do you compare to X? why should we choose you over Y?” Our position is that the comparison of different solutions for a given use case is the user problem, not ours. After all, that’s the beauty of open source: you have complete freedom to try it all by yourself.”

“We actually started by using licode, some 3 years ago. It worked very nicely, and was easy to use for conferencing. Eventually we had rewritten completely the erizo client side because of differences in the use case logic. While we contributed some code (for example we contributed to their recording code), but eventually, it was not flexible enough for the multiple different use cases we had in mind, and we also wanted more control (if only to learn in the process).”