Ever since I designed and wrote with an intern the infamous IE/Safari plugin, I had pledged to make it obsolete and redundant. Unfortunately, that had never happened. Until today that is. Come and check what this new free ($, beer) and free open-source (freedom) plugin brings you.

The original plugin was ahead of its time. Safari had not support for webrtc whatsoever, and neither had IE.

Fast forward half a decade, the webrtc-in-webkit project brought a lot of code to webkit, from which the apple safari team start implementing their own version, using libwebrtc (webrtc.org) under the hood for the underlying application. Members of the safari team mentioned specifically the project during a SF WebRTC meet up in June. Thanks for that. While it’s still work in progress, and some other specs (screensharing) do not seem to be part of the effort, safari has enough support for WebRTC 1.0 and ongoing developments that a plugin is not really necessary there. Yeah!

A lot of entreprises depend on software that support their business process written in ActiveX, e.g. to sync browsers, outlook, databases and many other Microsoft pre-10 software. It makes the transition away from IE much more costly than adding a small plugin. While some would argue that if you download something it should be chrome and not a plugin, a lots of IT departments disagree. They have a lot of expertise with ActiveX security testing, and plugin management through admin settings, and feel comfortable evaluating the risk, but wouldn’t let users download other software. Practically the result is simple, Win7 with IE is still representing more than 50% of the desktops in the entreprise world (Stats courtesy the GoTo team at Citrix, April 2017), and IE still does not support webrtc at all. Moreover While Edge has multiple ways of supporting WebRTC, Edge requires win10. Most of the entreprises, and the kiosks / displays in mall, and everything else that runs embedded windows, is stuck with IE for displaying web content.

The demand is pretty clear, but what’s on the offer side.

There are some open source generic projects (webrtc-everywhere, webrtc-for-all, …) pretty much all from Doubango telecom in paris. The code is GPL. They implement older version of webrtc 1.0 and could never really keep pace with the standard.

The same thing can be said about the closed source generic Temasys plugin, which does not implement the promises API, nor the track based API, and even less the sender/receiver/transceiver APIs. Following the excellent blog by Mozilla on the evolution of webrtc API, they implement stage 1, out of 3 stages. They also keep behind a paywall features that are now available in the free code like H264 support.

Then you have some specific plugin (specific to a platform and/or a product), and I am aware of at least three: Frozen Mountain, CafeX and Tokbox, but I’m pretty sure there are more out there, for almost all the companies that have entreprise customer need to fill that gap. Of course, those are of limited interest to you if you re not already a customer, as you wouldn’t be able to use their plugin in your product otherwise.

Now, coding a webrtc plugin , for us at cosmo, is not exactly a challenge. This time around it took us a couple of weeks. The challenge is to do it provably well and  in a sustainable way (super low maintenance).

The biggest burden of a plugin implementing such a fast moving spec is the maintenance. Best case scenario you need to upgrade at every browser release, worse case scenario, well, there are 200+ commits on libwebrtc every week. One cannot manage the maintenance of a plugin without a good management of libwebrtc. the webrtc-everywhere project request users to build libwebrtc themselves, and are stuck with a very old version, probably pre-chrome-50, still needing MSVC 2013. The webrtc-plugin, by related authors, is windows only, and more recent. It still requires you to patch and compile liwebrtc for M58, you remember: that infamous chrome/webrtc release with 4 critical security bugs in it.

The biggest problem being that almost every 6 months, the entire webrtc (and chrome) windows build system changes. Up to M56 (october 2016), the project configuration tool was GYP, then it was GN. Shared builds and 32 builds disappeared at the same time. IE plugins need 32 bits code. Then, Around December 2016, the compiler changed from msvc 2015 to 2017. Today it is still 2017, but since chrome has moved to a mix of CLang and MSVC 2017, it is likely to change soon. Each of those change required a major rewrite of any automated build scripts for libwebrtc. By major, I imply that many vendors are not capable of doing it. From our analysis, it seems that the Temasys plugin for example is still using a GYP-based build, which means they would be using M56 at best.

Clearly, the ecosystem is missing the right tools and there is gap.

At cosmo we have developed for our numerous native projects a complete build infrastructure for libwebrtc to shield us for that problem. Some of our builds are public, even some exotic ones like webrtc with double encryption or built with OpenSSL instead of BoringSSL. We are Starting to get quite a collection of configurations to install.Those builds are part of the continuous integration of all our native apps, wether desktop, mobile, or … IE plugin. There again, some project like this QT client for Janus VideoRoom (part of the “WebRTC A-Team” effort), have a public CI Dashboard.

Our KITE infrastructure also allows us to run as many test as we want not only on different browsers configurations but between them as well. We are not aware of any other test solution that not only allows to test against mobile browsers, and/or against IE with plugin for example, but also let you run all the tests and corresponding infrastructure on-premises as well as hosted. We can now test interoperability between IE + our plugin and any other browser, on a daily basis to check for regression and keep our plugin stable. 

The “provably well” was the challenge. How do you test how good a plugin is? How do you compare two plugins against each other and against the browsers with a metric that makes sense, that is easy to run by anybody, and provide reproducible results such as to sustain the FUD that, history taught us, other vendors and bloggers alike will undoubtedly spread? Our implementation is open-source, so the reproducibility is trivial to start with.

Thankfully one has the compliance test suite from the W3C (a.k.a. the wpt), which does exactly that: computing compliance of a given browser with the specifications. Since we also contributed a large portion of the WebRTC 1.0 tests, we had the expertise in house to use that. Of course, IE does not support ES6, only ES5, but this is a problem that has been solved by others many times around. With a few node packages and a little node project to automate it all, running compliance tests on browsers and on IE + plugin is now a mater of seconds (try “npm test” from a clone of our GitHub repository, below).

Long story short (and you can see the long 1099 tests version there) we ran the test on chrome, firefox, Edge, and then IE with our plugin.
  We tried to run with the Temasys plugin, but without modification to the tests, and even using their modified adapter.js, it was just hanging IE, an we could never successfully run all the 1099 tests. We eventually managed to make most of the test run (830+ instead of the maximum 1099). Basically the tests  have to wait for their AdapterJS.webRTCReady() callback before they can start creating peer connections. This is not the case with the browsers, and not with our plugin either. In any case, most of the tests would fail, as the RTCPeerConnection implemented by Temasys plugin does not support promise-based APIs. e.g. when calling pc.createOffer() in accordance to the specifications, the error “Argument 2 is not optional” is thrown by the Temasys plugin, because the method is expecting callbacks to be passed to the method.
  We did not run it on apple / Safari or STP yet, once we’ll have done it, we’ll update this post. Last time we ran it, it was scoring better than all. 
  The browsers here, and our plugin, do not use adapter.js when running the tests. That explains why the result reported are below what I reported in a previous post last year.
  By design, all the IDL tests will fail with our plugin (no “Interface” in the IDL sense are available), so it is expected that our score will be always lower, for the same level of webrtc support from a web app perspective.

394 : Firefox
360 : Chrome
270 : IE+CoSMo
99 : MS Edge
38 : IE+Tem.

Most of the failing tests are related to missing Sender / Receiver / Transceiver APIs in each of the above implementations. It’s gonna be interesting to see who will implement the first. Firefox had definitely an early start, and already supports Unified Plan, but google is pushing hard to see that soon, and we have agility and speed on our side. Let’s admit it: it would be highly ironic that the most WebRTC compliant browser be IE with a plugin, even if only for a short while 🙂 The fact that our plugin will never pass the IDL tests in the test suite makes it doubly challenging though.

The code is open source and free, already support H264, and support for screen sharing, proxy (without authentification), and other should come quickly. Enjoy:

https://github.com/CoSMoSoftware/CSM-IE-WebRTC-plugin-shim

If you need special features, or have a request, do not hesitate to contact us.