Learning more about the Kurento Open Source Media Server
Dr. Luis Lopez is Kurento.org project lead and coordinates the creation of the FIWARE Stream Oriented Generic Enabler, which is fully based on Kurento. Dr. Lopez also coordinated the NUBOMEDIA research project, where an elastic cloud infrastructure fully based on Kurento is currently under development.
In December 2014 Dr. Lopez presented FIWARE and Korento at the Paris WebRTC Conference. Already back then we discussed the option of doing an interview on our blog. Now, with the acquisition of Jitsi by Hip Chat – Atlassian, this has become even more relevant.
What is Kurento all about and who is it targeted to for?
Kurento.org is an open source software project providing technology enablers helping developers to create rich applications involving real-time multimedia communications and real-time media processing. The most significant of these is the Kurento Media Server (KMS): a modular media server providing its capabilities through pluggable components that can be connected among each other for creating complex media processing pipelines combining real-time communications, recording, transcoding, routing, computer vision, augmented reality and any other processing features you may wish to add as a module. KMS provides off-the-shelf a mixing MCU (Multipoint Control Unit), an SFU (Selective Forwarding Unit), chroma filters, face detection filters, marker augmented reality filters, image overlay filters, alpha blending mixers and many other complex processing features thanks to its direct integration with the GStreamer and OpenCV projects.
Is Kurento built specifically for WebRTC or is it more of a general purpose media server?
Kurento Media Server is a general-purpose media sever. In fact, WebRTC was not included as a supported feature in its initial conception. However, in 2012 the European Commission decided to fund the NUBOMEDIA project, which is still under execution and which aims at creating an elastic scalable media server supporting WebRTC. Since then, we have been working on our WebRTC stack, which is still work in progress. For example, in the next few months we will add features such as DataChannel support, statistics gathering, improved congestion control, etc. These efforts have been strengthened in the last few months thanks to the synergies we have with the openwebrtc.io project. We have currently a fluent cooperation with the Ericsson people for enhancing the low level GStreamer capabilities that both projects share. This cooperation is still concentrated on specific aspects but I think that, with time, both projects may converge to a common and reinforced GStreamer WebRTC stack, which could benefit both the openwebrtc and the Kurento communities.
Although WebRTC is one of the key features of KMS, KMS will continue to be a genera- purpose media server with support for other media transport protocols including RTP, RTSP and HTTP and to a wide variety of audio and video codecs and containers. The purpose of KMS is not to be a WebRTC media server, it is to be a useful media server for developers.
In your eyes, what are the greatest advantages of WebRTC and in what way did it help you build Kurento ?
WebRTC is a technology for developers. It has been designed for making simple the creation of real-time multimedia applications. Today, thanks to WebRTC, any of my students can create in an afternoon an application whose creation would have required a team of expert developers working for several months few years ago. This is the revolutionary aspect of WebRTC: the democratization of real-time communication technologies. If you think about it, real-time communication services have been owned by a selected club of large companies. This has somehow made difficult for small players to play into this walled garden, which in my opinion is the main reason why there has not been much innovations in this area. However, WebRTC changes completely the rules of the game. Now, anyone can create their very own service and adapt it to very specific needs and requirements in quite a simple way.
The browser WebRTC stack is perfect for creating services involving peer-to-peer communications, but when you want to go beyond that, you need to introduce a server side infrastructure for complementing the browser capabilities, and this is where Kurento Media Server may play a role. Hence, the browser WebRTC stack and the Kurento Media Server stack have somehow the same objective but in complementary sides of the problem: to make the life of developers simple and to allow them to concentrate on creating innovative application and services and not on fighting with tricky details of media technologies.
Do you provide only the server side or are the browser and mobile clients part of the Kurento offering?
The Kurento project is currently quite concentrated on pushing the development of the Kurento Media Server and we don’t have plans, at least in the short term, for investing significant resources on the client side. However, in the ecosystem of companies and developers around Kurento this is indeed happening. For example, Naevatec, one of companies involved in Kurento, has created an Android stack specifically designed for interoperating with Kurento Media Sever and an iOS stack is on the way. In addition, as part of the NUBOMEDIA project activities, specific client APIs are being created for Android, iOS and Web by relevant industrial and academic partners including Telecom Italia, Fraunhofer Fokus and VTT. I think that, by the end of this year, these activities shall enable to have a full-featured stacks both on the Web and on smartphones with direct integration into the Kurento ecosystem.
Now KMS core developers are much more concentrated on the infrastructure side of the problem than on the client side one. Most of our efforts are devoted to transforming KMS into a cloud media server. At a first stage, this means to enable the deployment of KMS into different types of clouds in a seamless way, which is somehow already achieved for both Amazon and OpenStack based clouds. However, the really ambitious part is the second stage, where we want to offer the abstraction of an “infinite scalable” media server. Currently, most auto-scaling cloud mechanism for media infrastructures consist on instantiating independent media servers which don not interact among each other, so that the services that can be provided are the typical ones (i.e. group communication calls). Our vision goes beyond and requires a complex orchestration layer managing to expose those capabilities through an unified service API abstracting the fact that there are different media server instances, so that developers feel that they are working with a single “super” media server (which significantly simplifies the development process) having elastically scalable resources. This brings the possibility of creating, for example, very large distribution trees for real-time multimedia content.
There are other open source media servers out there; can you give us the few major advantages of Kurento?
Although the Kurento project comes from a telco philosophy, nowadays Kurento Media Server design is more adapted to being used in the context of Web technologies. For example, instead of exposing the media server capabilities directly through signaling protocols such as SIP or XMPP, which assume a specific communication models (i.e. calls models), KMS is fully agnostic to signaling. We just expose a control API suitable for the direct management of the media capabilities (e.g. recorder, WebRTC endpoint, Player, face detector, etc.) and not exposing high-level communication abstractions such as calls or rooms as other media servers and media infrastructures do. Hence, in general, if a developer just wants to make WebRTC calls following standard communication models, she may probably find Kurento Media Server too complex because the notion of what is a call or what is a room needs to be implemented by the developer. However, when the application is somehow beyond the standard “calls” and “room” models, Kurento is advantageous because makes possible to have full control on how the session is created and what specific capabilities are involved into it.
Can you give us a few real-life use cases where Kurento is being used today in production?
Kurento is part of the FIWARE Accelerators program (a program of the European Commission funding with 100M€ the participation of start-ups in the FIWARE ecosystem), and due to this there are now around 100 startups creating applications involving somehow Kurento technologies. Most of them are still in early stages, but among them there are e-learning applications, sports event retransmission applications using augmented reality overlays, smart-city applications for traffic control using different types of computer vision filters, click-to-call applications for putting in contact experts with users, etc.
In addition to this, Kurento is having success in the US, where some relevant startups are creating large deployments of Kurento for providing WebRTC services requiring features such as recording or RTMP interoperability. Hopefully, in the next few months we’ll be able to share with the community the detail of these success stories.
Any plans ahead for Kurento or new developments based on WebRTC that you would like to share with us?
Currently, 90% of the Kurento initiative is supported by public money coming from different research projects and 10% through private money coming from company contributions. Our plan is to put this model upside down so that, on the next couple of years, Kurento plays a relevant role in the media server market and is capable gathering all its resources from industries and developers using it. For this, we have some immediate plans such as consolidating our professional services line, which is already in place in collaboration with Naevatec, and which is working quite well in the last few months. Beyond that, we have some more ambitious plans for transforming Kurento into a legal entity of some kind. We are thinking about a foundation or even a start-up. Through it, we plan to implement a very disruptive idea we have in mind for bringing to reality our initial vision of communication services going “beyond transport”.