I want to support #WebRTC, do I really need to use google library?

WebRTC has been a magical word for the best part of the 2010 decade, starting, if we had to put a date on it, with 2011 Google IO presentation. From conversations as early as 2018, and many small signs (dropping support for official mobile release in m80 release notes), it was clear that, for Google at least, the WebRTC star itself was already the past. Still, more people depend on webRTC, or want to adopt it, today than ever. What are the options out there? How should one prepare for WebRTC in 2020?

WebRTC implementation? or maybe RTCWeb? What’s the difference?

The word WebRTC is used to refer to the official JS APIs in the browsers, and the official implementation of the entire stack. The former is standardised as part of HTML5. The later is code resulting from the GIPS and ON2 acquisition open-sourced and under the, sometimes frustrating, governance from Google. It is implementing everything, from the WebRTC API, all the way down (codec, RTP, encryption, ICE, network, …), including de facto everything needed to be interoperable on-the-wire, i.e the RTCWEB specs. For some time now, people have called the implementation libwebrtc, and that helps removing the ambiguity between the standard document, and its implementation by google.

Where can I find a webrtc implementation to … inspire myself from?

If you are looking for a WebRTC implementation, you have to look on the browsers side, or anything that implements HTML5.

Firefox has its own implementation of webrtc (the API), most of it directly in JS, on top of different components and libraries, most often from open source projects. Firefox ICE implement for example is inherited from the reSIProcate project, and their media engine (codec + RTP) is borrowed from libwebrtc.

Safari has also borrowed libwebrtc for their RTCWEB implementation, with a lot of optimisations on the codec side to support hardware acceleration, and apple APIs in general, as much as possible. The WebRTC JS API implementation was bootstrapped from contributions by the WebRTC-in-webkit project by Ericsson Research, italia, centricular, and myself.

If you go deep enough, you will realise that there are maybe only 2 or 3 C/C++ libraries out there for ICE, SSL, SRTP (respectively), and 1 for SCTP (needed by the data-channels), so eventually everybody use the same ones.

Do I really need all of that? What is the minimum I need?

Some distinctions needs to be made.

If you want to implement the HTML5 WEBRTC JS API, for example, in react-native, Qt QML, or other JS compatible framework to be able to reuse some existing JS libraries or complete websites, you are likely to need all of that. However, this is usefully not the case, and if this is what you want, some projects or vendors got you covered (React-native, Qt QML)

If you just want to be WebRTC compatible or compliant, i.e. to interoperate with web apps running in browsers, whether you are a native app or a gateway, you do NOT need to implement WebRTC, but just RTCWEB.

In other words, you can use whatever API you want, you just need to be sure that what you send (on-the-wire) to the browsers is compliant. In certain cases, the specifications themselves recognise the difference between browsers and gateways, and lower the expectations for gateways (e.g. the ICE part can be much simpler when you know you’re on a public IP).

Is libwebrtc the only library around? is it the best?

Libwebrtc is famous because it was the original one, it is maintained by an army of 100+ google engineers (plus all the chromium infrastructure and tooling team), and it is used by most browsers. While WebRTC was not fully standardised, the fact that it represented most of the code in Chrome (but not all, check this) was really appealing, as the target was moving fast. It’s likely to be less and less the case from this year on as the WebRTC 1.0 spec has just reached Candidate Release level, the last level before becoming an official standard.

libwebrtc is a client-side implementation, that is less than ideal for server-side webrtc implementation. Most if not all of the open-source SFU, and many closed source, have their own stack, all different which each other, although interoperable on-the-wire. So, when you hear that there is only one implementation out there: libwebrtc, it’s far from the truth. One could take any WebRTC media server and have a fully compliant implementation, or the firefox source code, ect. I’m not saying it easy, I’m saying that there are many more options that people usually think. I’m also saying that, in most cases you do not care about the WebRTC JS API and just need to implement RTCWEB.

A few years ago I had made a list of the implementations / media servers out there. it also include the signalling-only (p2p media), but it is still useful to illustrate how many choices you have, and to start from.

Nowadays, you have multiple choices. If you’re looking for something lightweight for embedded devices, Janus and PIPE comes to mind, both written in C. If you’re looking for an implementation in JAVA, libjitsi is a good start and is used in many derivative products like red5 or ant media. There is a GO implementation called PION, and a python implementation named aiortc. The de facto standard webrtc SFU used by W3C and many IETF members in general, and google and Apple in particular, for compliance testing is called medooze. This is also the SFU used to power the millicast streaming platform media path.

Do not be afraid to mix different implementations in your system. Actually, you should as the same rtcweb implementation is not going to be good for both server and client-side. If you only use web app, browsers are taking care of you, otherwise, libwebrtc seems to be the most popular choice client-side nowadays, but a lot of people, depending on their preferences also use e.g. GStreamer.

Trivia / Fun facts to close this post.

Facebook owns the most popular apps on the market. For those curious about what webrtc stack their use, it is notorious that FB messenger uses libwebrtc stack. The fact that they forked it in 2013 and never quite got to update it is generating a certain number of bugs that have entertained the browser community for some years now.

Whatsapp is based on the less known PJMedia, part of PJSIP library. PJMedia packs a full media engine (voice only) in 56kb! of course, lots has been added on top of it, including but not limited to end-to-end encryption (more on that on a later post). How they dealt with the GPL license is unknown.

4 thoughts on “I want to support #WebRTC, do I really need to use google library?

  1. Hi Alex,
    the most interesting part of the article is unclear:
    ā€œ
    From conversations as early as 2018, and many small signs (dropping support for official mobile release in m80 release notes), it was clear that, for Google at least, WebRTC was already the past.
    ā€œ
    Do you mean that google is deprecating WebRTC, replacing it with something new or you mean it bets to webrtc nv?
    Would be cool to solve this ambiguity.
    I understand that maybe this is your writing style but I asked several people to get the meaning and get several different results. Write it simple for stupid part or the class, please;)

    1. WebRTC used to be, at google, a very sought after cutting edge project where the best and the brightest engineers could go and make a visible difference. For some years now, it is not the case anymore. Appart for the standard people, most of the early days webrtc engineers have moved onto more appealing projects. To the point where there is barely enough people left in the soon to be closed W3C Working group to finish a dozen of smaller specs.

      WebRTC 1.0 is now a fully matured project, with little innovation left, which shifted to maintenance mode. It is here to stay as a component of chrome, like any other HTML 5 API and component, so there is absolutely no fear to see google dropping it anytime soon.

      WebRTC NV is almost dead as it, and the main components of what originally was proposed in WebRTC NV have found their way in other groups under different names. Some of the original engineers have followed this path, which leads them away from WebRTC in a sense (and into e.g. the web transport, Media Group, …..).

  2. Hi Dr,
    thanks a lot for this thorough explanation! Now it make a lot of sense. You are the only one person who I follow on webrtc subject so I need to understand everything in your posts. Sorry for bothering you.

    For these who don’t get point about “dropping support for official mobile release in m80 release notes” – this means that google don’t build IOS and Android builds anymore after M80(build version of chrome).

    1. It’s a little bit different. Google still maintains iOS and android code, and corresponding builds. They still have android and iOS builds, including on real devices in their automated build, testing and integration platform. However, they do no provide pre-compiled packages (e.g. cocoa pods) anymore.

Leave a Reply

Your email address will not be published.

Time limit is exhausted. Please reload CAPTCHA.