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.

Thanks for sharing Alex

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.

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.