Browser plugins are a nasty business. A WebRTC Plugin is doubly-complicated.
UPDATE: There’s no real need for a plugin any longer. All modern browsers support WebRTC, and people are using Electron with WebRTC where they want a native app or when they don’t want to support all browsers.
Here’s the thing. We thought a few months back that there’s a solution out there – not one, but TWO plugins available. One from Temasys and the other from Priologic. That was 3 months ago. A lifetime.
When you go today to the Priologic github project for the WebRTC Plugin this is the message you see in the readme:
This code will only work with an antiquidated version of the Google WebRTC code base and was only at a demo-able state, not production quality. We have stopped work on this project because Temasys has a free IE plugin and Doubango has an open source one (see https://github.com/sarandogou/webrtc-everywhere). If you want to develop your own plugin, we suggest starting from the Doubango code base.
To say the truth, there were no changes to the code since the press release about this one. It was dead before it even started. On the bright side, Priologic were sensible enough to discontinue it instead of pushing forward with something that made little sense for their current business.
Your options today?
- The Temasys plugin, a closed binary for better or worse
- Doubango’s webrtc4all plugin, under the ugly and unusable GPLv3 license. This one has too many “legacy” codecs supported while lacking Opus
- Then there’s webrtc-everywhere which uses a mix of BSD and GPLv3 licenses that actually make some sense
That third plugin option? It was hard to understand if it is a brand new one or the continuation/fork of the Doubango offering. This only goes to show the abysmal nature we are at with it (=not enough documentation to begin with).
To these options, we can add all of the WebRTC API Platform vendors who have their own plugins that either wrap WebRTC or implement a variant of it on their own.
This brings us to a headache…
I’d like to give a few more attributes to check when selecting such a plugin for your own WebRTC service – things that might not be apparent at first glance, but should be taken into consideration.
1. Plugin size
Not all plugins are created equal. They differ in their size, and while this may seem petty – just remember where we started with WebRTC: the need to reduce end user friction.
The larger the plugin, the more time it will take to download and install it, and the more frustrations it will end up causing to users.
I once took a trip to China and had to update my company’s video calling app. It wasn’t too big, but it took 10 minutes… not the best of experiences I had.
The size of the plugins I’ve seen for WebRTC begin at around 4 Mb of a download and top 10 Mb.
Ask for the size before you select.
2. Browser versions supported
Plugins are tough. With multiple versions of Safari and Internet Explorer, spanning multiple versions of operating systems; it isn’t always obvious which ones get supported by a plugin.
Some will focus on IE 9 and above. Others will try to bring IE 8 to the fold. At times, even IE6 will be considered.
Safari might ignored altogether.
Don’t assume that a plugin that supports IE will run on all of its versions. Check. And then also check if Windows XP is supported.
Make sure you know where your customers come from so you’ll know which compromises to make: a plugin that supports more browsers takes more time and investment to develop and maintain – something you might not want to rely on if you prefer a lean and mean operation from the plugin supplier.
3. What API?
So they say it has WebRTC inside. Great.
What API do you end up using there? Is it a WebRTC API or something else?
Which “version” of the WebRTC API does it contain? The latest one off webrtc.org? Something stale from yesteryear?
How do you embed the plugin into an existing WebRTC service? How much work is required for that?
Check these things to make sure they fit your expectations.
4. What’s not included?
Now that you do know it is WebRTC, time to check what features aren’t supported.
Screencasting will usually be left out, and if it is there, start asking how permissions and security are going to be handled (not trivial).
Make sure the features you need are there to begin with.
5. What’s included that “shouldn’t” be there?
Did the plugin include a bonus of sorts? Something not available in WebRTC itself, but the plugin supplier decided should be?
An additional codec or 10 codecs maybe? These add up to the size of the plugin and might even complicate licensing and royalty issues with the plugin.
My suggestion – pick a plugin that is as neutral and as close to the vinyl WebRTC implementation as possible.
6. Upgrade procedures
Google releases a Chrome version every 6 weeks or so. This means new features as well as bug fixes in WebRTC every 6 weeks. Just check their roadmap for WebRTC.
How often do the plugin supplier update his own plugin? What are the upgrade procedures that should be taken by someone who already installed the plugin on his machine? Do you have any control over the upgrade procedure? Can you stall it for a couple of weeks to get your own service in order and supportive of any changes made?
7. Open source, free or paid?
Which model does this plugin come with?
Open source? Great. Is it GPL or something a bit more permissive and accommodating?
Is it free, but closed source? Is that good or bad for you?
Do you need to pay for it? Might not be such a bad idea to have an SLA in place…
8. Hosting
Who is going to host the plugin?
Is it up to you, or is that something the supplier offers? Does this hosting include a CDN? Does it cover your target audience?
Why is this important?
Until Microsoft and Apple decide to join the party, we are going to either ignore their browsers, use Flash (yuck) or have a plugin in place. None of these options is great, but we make do with what is available to us.
The plugin angle is becoming more interesting, but the vendors who offer them have their own vested interest. It is best to align with what you need and not go for the first plugin you find.
Need to know where WebRTC is available? Download this free WebRTC Device Cheat Sheet.
Thanks tsahi for this nice blog.
I think you a re right, finding which criteria/questions are good to choose a plugin is the right approach. In my presentation at webrtc expo world, that’s exactly the approach I advocated: ( http://www.slideshare.net/alexpiwi5/plugin-for-other-browsers-webrtc-conference-and-expo-2014 )
First, even though I’m a vendor, so I’m biased, I would like to say again what I always tell people:
Trust no one, test them all.
For us, security comes first, and you touched on that even though you did not make it a criteria. I would argue that you might want to make it the first criteria.
Then comes the maintenance and quality pledge. EasyRTC plugin was a good start, but priologic did not have the capacity to support the maintenance such a fast moving technology requires. Expect to spend 2 full time equivalent on this.
As for the quality, you have to be able to carefully pick which version of webrtc library you integrate (there are many commits a day) and test interoperability against all browsers / OS pairs.
You mentioned quite rightfully that browser release cycles are of 6 weeks. webrtc4all hasn’t been updated between august 2013 and march 2014, or since august 2014.(https://code.google.com/p/webrtc4all/source/list?num=25&start=72).
Sarandogou with webrtc-everywhere might have a better license, but the question of who the copyright owner is remains. There haven’t been a lots of code commits since early august as well. Meanwhile, chrome 37 was released as stable on september 16 for mac and september 24 for windows …. (http://googlechromereleases.blogspot.sg), firefox 22nd was released on september 22 (https://www.mozilla.org/en-US/firefox/32.0/releasenotes/),.
Our experience is that the webrtc side of things (upgrading the source code, recompiling, testing, … ) is taking most of the time as opposed to the plugin layer itself.
Thanks for sharing Alex
Tsahi – you are quite right in saying that there are many issues in selecting a plugin and your list along with Alex’s suggestion of security is a good place to start. We have just upgraded our Platforms page (icelink.fm/platforms) that shows what features IceLink supports on each platform, where plugins are used, etc. and also added an FAQ page to help clarify the confusion we also see in this area, but in summary here are the answers to your list for IceLink:
1. Plugin Size
On IE, IceLink’s ActiveX control is 1.2M. For any browser other than Chrome, Firefox, Opera or IE (e.g. Safari) that can use Java, a Java applet is used and the jar file is 6M. The size comes from the need to support multiple operating systems (Linux, Mac, Windows).
2. Browser versions
The oldest ones IceLink supports are Chrome 28, Firefox 23, Opera 18, IE 6 and Safari 6. Everything from that forward is fine.
3. What API?
Icelink uses its own API which it calls a conference API – it has to. One of the main things we are asked about regarding WebRTC is application portability and future proofing. Given the WebRTC spec is not finalized, how ORTC will fit in is under discussion but not firm and then who knows what Apple will do, it was the only way to go. We want people to do peer-to-peer processing with WebRTC starting now without waiting for a single standard that may or may not ever come.
In browsers that have native implementations (Chrome, Firefox., Opera) IceLInk detect’s that the native implementation is present and just invokes the native implementation. When WebRTC 2.0/ORTC comes out or Apple does something, IceLink will do the same for the other browsers. In the meantime IceLink provides plugins that work for those platforms. Also as noted in other WebRTC posts, the business need for WebRTC isn’t just Web anymore – its about peer-to-peer processing in other environments such as native iOS and Android for mobile apps. Complement to the standards folks – what has been created in WebRTC is so good people want to use it outside of the web, so IceLink provides the same API for a number of non-Web application environments.
4. What’s left out
Applications written using IceLink co-exist with applications written using the implementations on Chrome, Firefox and Opera so IceLink supports whatever they all support. If there is something they don’t all support, we don’t either since otherwise the co-existence wouldn’t work.
The only exception to this is that IceLink does not support reliable data channels, but it is under development.
5. What’s included that shouldn’t be.
The reverse of the answer to question 4. Since IceLink can’t produce something Chrome, FIrefox or Opera can’t consume in their implementations, nothing that can affect the actual transmission. IceLink does have a couple of small things such as a configurable video screen layout manager since everyone asked for it.
6. Upgrade procedures
We produce a minor build approx every six weeks to sync with Google and we test against all the platforms. Customers can purchase support which gives them major versions (typically twice per year) as well. Since customers are not running on a hosted version (unless they host it themselves), they can replace with a new version or not at their discretion. Standard product maintenance. We offer support levels from e-mail up to 24×7.
7. Open Source, Free or Paid
Paid, but not very much since it is on a per developer basis with no run-time fees.
8. Hosting
IceLink is licensed, so customers can put it wherever they like.
9. Security
IceLink supports full 128-bit AES encryption with key exchange using DTLS.
Ted thanks for mentioning IceLink.
I don’t see it as a pure plugin solution. Somewhere between a plugin and an API platform. That’s why I haven’t mentioned it directly.