One of the most vexing challenges for WebRTC developers is “what do you do with IE and Safari?” Do you ignore them? Tell your users to use something else? Can you even tell them what to do? Maybe you fall back to flash? There are no easy answers and WebRTC is supposed to be easy, right?
Perhaps you just wait and hope that Microsoft and Apple implement WebRTC soon? This brings a lot of risk – what exactly are they going to implement? For Microsoft it seems it will likely be ORTC, definitely not the current spec. When exactly are they going to implement it? What is Apple going to do? What will you miss out on in the mean time?
A small number of vendors have been working on plug-ins to address these issues and broaden WebRTC applicability. Most of these are immature, proprietary, and closed to those vendor’s audiences.
Just this Monday, Temasys announced something different – a free plug-in to Internet Explorer and Safari that anyone can grab right from their CDN. We caught up with Dr. Alex Gouaillard, CTO of Temasys to ask him about this project.
{“intro-by”: “chad“}
webrtcHacks: Before we get into the new plug-in, I would like to cover another open project you worked on – appRTCDesk. Can you tell me about that?
Alex: appRTCDesk is a section of our Github repository where we host desktop reference clients for WebRTC. There are some developers that may want to build native applications for Mac, Windows, and Linux. Google’s take on things is that if users want to use WebRTC on a desktop, they should use a web browser. We aren’t here to argue with them on this, so that’s why appRTCDesk is hosted on our Github repository and not in the webrtc.org repository. It interoperates with the appRTC.appspot.com website, and the appRTCDemo iOS and Android clients provided at webrtc.org. It provides support for GAE Channel API the same way appRTCDemo on Android does through webkit and a JS callback, and leverages Qt for the GUI. It was mainly developed by Francois Regnoult.
webrtcHacks: Of all the projects you could work on, why did you start that one?
Alex: Well, we have a strong open source background. I was very active in the ITK / VTK / CMake communities, and founded two start-ups around those Technologies. I believe that fostering an active community and contributing back to that community is an important strategic move for tech startups.
That participation allows you to demonstrate technical expertise, and drive awareness. Then, by carefully choosing where you draw the line between the foundational technology and the proprietary extension or enhancements that are key to your business, you pave the way to building a successful business. That is the approach we are taking with WebRTC. We know that one key to our success is the success of WebRTC, itself.
When we started working on WebRTC in 2012, the technology was really in its infancy. There were a lot of gaps and lack of parity between different versions of the reference code across operating systems, supported browsers, and so on. Some have used these gaps to create FUD, which they hope will slow WebRTC down, as a whole. We see this as a challenge to building confidence in WebRTC with clients and potential investors.
Whatever the motivation — maybe these critics want to buy time to catch up, or they aren’t the ones getting the PR for driving the standard, or it’s not in their interests to have a technology like WebRTC get traction because they have no way to counter that with their own products — this is harmful not just to us, but to everyone.
We are happy to take a different approach.
webrtcHacks: Was it a similar story for these plug-ins? Why did you take the leap from desktop apps to building plug-ins for both IE and Safari?
Alex: First, we did not start with appRTCDesktop. We actually provided iOS enhancements first. Then it was not more complicate to do the plugin, as we were getting knowledge about both the specs and the reference implementation. Eventually it was identified as a major impediment to the success of WebRTC, which could not be ignored.
Second, all the drama around it just got on my nerves. It bothered me and the rest of our team to see so many people using this complaint as a reason not to invest in WebRTC, or not to adopt the technology. And, the more I thought about it, the less significant of a problem I thought it should be, from an engineering perspective.
Finally, we had some internal debates about how to answer questions from people we talked to about why supporting IE and Safari was relevant or not in terms of our own efforts to build our business.
My CEO and I agreed that if we could do a proof-of-concept in six weeks or less, then having a plugin for IE and Safari was probably not something we could leverage in terms of commercial value to us. We made a bet — there was beer involved. And, by making the plugin generic and solving this for everyone, we would have more impact than limiting it to work only with our stack.
webrtcHacks: Several vendors are charging for these capabilities? Why are you doing it for free?
Alex: Yes, we have seen many vendors going into the gaps we’ve talked about before, for the past two years. They solve a small problem, and propose a limited solution and attach a price tag. Then, within 2 to 4 months, everybody has the same capacity. It’s a very shortsighted approach and provides no significant competitive advantage.
Look at the way the MySQL community works. It’s the perfect example of what we want to achieve. I’m honestly very surprised; I really thought more companies would contribute to the community by working on the small incremental fixes to the reference code and contributing back to the community, but most seem to do one of two things: they wait for Google/Mozilla to do it, or try to do it and keep it for themselves.
The plugin is an enabler. It fits within our philosophy of contributing back to the community and providing tools to help developers. We have much deeper capability and we can differentiate in other ways.
Given all of that, Temasys thinks the real commercial value is in providing infrastructure and great tools to make WebRTC capability “easy to embed, and scalable like the web.”
webrtcHacks: So how long did it actually take?
Alex: Within six weeks after we started development, we had the plugin working in limited use cases on IE and Safari. In another six weeks we had it working on all reference code tests, on appRTC, and on our own demo site.
The week preceding our public announcement of the plugin, we worked with Bistri to validate our design. We provided them with the plugin and some example implementations. They managed to upgrade their SDK and their platform to use the plugin within a matter of days. This shows that it’s generic (enough) and easy (enough) to implement.
They managed to upgrade their SDK and their platform to use the plugin within a matter of days
webrtcHacks: So I guess you won the bet you made with your CEO?
Alex: Yeah, and that’s why our video showing off the plugin has me saying “Did it!” at the end. It is a little humor for us to share regarding the original wager between me and my CEO.
webrtcHacks: I am surprised there are not more plug-in projects like this? What is so hard about building a plug-in for IE or Safari?
Alex: The first challenge is that IE and Safari do not share the same plugin API. IE uses ActiveX while safari use NPAPI. We also wanted to stay as close as possible to the reference C++ code, not only because we know it well, but because it makes it easier for us to stay as close to the standard as possible. For such a fast moving technology, it’s important to keep the required effort involved in ongoing maintenance low. For these reasons we chose not to go for a full re-write, as perhaps others have.
To our benefit, we had the example of GoCast.it, who one year ago developed a similar plugin and open sourced it. Their plugin was proprietary, but it was based on the original source code, and they used a great piece of middleware called FireBreath, which abstracts the plugin API for the developer. Not only does it remove the need to learn about either ActiveX or NPAPI, but it also allowed us to maintain a single project, while covering both IE and Safari targets. IE was the main target, but support for Safari is a plus, and it came for free, so we chose to pursue both.
The original authors of the code were very responsive and supportive in addressing some early issues – the code was not compiling since it was based in an older version of libJingle. A big thank you is in order for Manjesh Malavalli for his original work, and his much appreciated support. The FireBreath community was impressive as well. They answered emails on their mailing list within hours, and so far they’ve always led us in the right direction.
webrtcHacks: How do developers use these plug-ins?
Placing a few lines in the JavaScript of the page is all you need. We provide modified versions of the standalone tests from webrtc.org, as well as a modified appRTC code, and other working examples for inspiration.
Typically, here is the logic flow which is pretty trivial:
- Check for WebRTC support and/or browser
- If WebRTC support is not available, you check to see if the plugin is installed
- If not, you prompt the user to download and install
- If yes, you add a plugin object to your DOM
- Finally, there is a little bit of javascript glue that ties into the WebRTC plugin
WebRTC API calls are then wrapped in such a way that using the plugin is transparent to existing code. For appRTC, for example, we put it in adapter.js. We worked really hard to find the most generic, and least invasive solution. One of our primary goals was to provide a solution that would work with an existing site under Chrome or Firefox, and have it work with the plugin, with minimal or no modification except for installing the plugin, itself.
Placing a few lines in the JavaScript of the page is all you need.
webrtcHacks: This is all open source right? Where can developers find the code?
Alex: Our goal is to remove the “what about IE and safari” question from the Devs and Investors’ table long enough for a native implementation to land.
webrtcHacks: So it isn’t open source?
Alex: For the license, we will release the plugin free as in beer. Meaning, you don’t pay for it, but it’s not open source – free as in freedom. There are a lot of security concerns like camera permission, etc. that we want to be sure we handle correctly before we release the source. Nothing would hurt the community more than a bad plugin.
Also, we are a little bit concerned of the potential uses of fork of this plugin. While the original open source version of WebRTC is available for all, it’s not that easy to make a plugin out of it. If we were to open the plugin source right away, it would be trivial to weaponize it and use it in malware. We’re still having an ethical debate internally.
webrtcHacks: Aren’t you worried you might receive some pushback from the community on this?
Alex: We think that for the time being, making it generic and vendor-agnostic, being very responsive to the community, and very fast at releasing the features when they become available while keeping it close source is the best immediate solution. We hope that MS and Apple will deliver fast, so this will not be necessary anyway.
If anybody could convince us that there is a use case that justifies taking the risks above, or that there is a way to mitigate those risks, or both, we’re happy to listen. If some companies want to integrate this in their product …. I’m tempted to say they had better use the reference code, but we’re also open to discussion.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
// This function detects whether or not a plugin is installed // Com name : the company name, // plugName : the plugin name // installedCb : callback if the plugin is detected (no argument) // notInstalledCb : callback if the plugin is not detected (no argument) function isPluginInstalled(comName, plugName, installedCb, notInstalledCb) { if (isChrome || isSafari || isFirefox) { // Not IE (firefox, for example) var pluginArray = navigator.plugins; for (var i = 0; i < pluginArray.length; i++) { if (pluginArray[i].name.indexOf(plugName) >= 0) { installedCb(); return; } } notInstalledCb(); } else if (isIE) { // We're running IE try { new ActiveXObject(comName+"."+plugName); } catch(e) { notInstalledCb(); return; } installedCb(); } else { // Unsupported return; } } |
Sample from Temasys’s adaptor.js
webrtcHacks: On the topic of integration, how does this work with your back-end? Does the plug-in require the use of your API or any of your services?
Alex: Absolutely not! This is vendor agnostic. We are actually working with a few sites like netscan.co to have them support it. Eventually, we think that it might become the de facto standard for supporting WebRTC on IE and Safari, until MS or Apple implement it, or propose a new technology that is backward compatible like ORTC.
If it was tied to our platform, it would not remove the question from the table once and for all, it would just be business as usual, and you can already find many vendors out there playing this game.
webrtcHacks: OK, so in general what do you think the major downsides are to a plug-in approach vs. native support?
Alex: There is no question. We hate plugins, with a passion. Some browser vendors put us in the situation where we do not have the luxury to wait for them to act on a critical and loudly expressed need from their user base. We sincerely hope that this is only a temporary solution, and we don’t want people to get the impression that plugins are the magical way to bypass what browser vendors do (or don’t do). Native implementation is always best.
This is one of the reasons why we joined the standards committees. Next week, I will be in Washington, DC, at the joint IETF / W3C WebRTC working group meeting, where I will present the state of interoperability. I intend to reiterate this message while I am there. Temasys has no bias toward a particular browser, OS, or hardware platform. We want WebRTC to be adopted as widely as possible and we will continue to push native implementation as much as we can.
webrtcHacks: Will this work on mobile? Safari iOS?
Alex: No. This is desktop only. We provided iOS native code in the reference code – that is our main contribution so far- so that people can have one way to support iOS there.
As far as mobile BROWSERS are concerned, apple policy forces their version of webkit into all other browsers, and their version of webkit does not support WebRTC … yet. There is really nothing that can be done by anybody else than Apple there.
You already saw that Apple open a bug in webkit to bring WebRTC in. Now a possible problem is that the number of active webkit committers went from around 450 to 200 when chrome forked blink out. I’m also not sure how much domain expertise is available. Frankly, we are open to talk with Apple to help them implement WebRTC in webkit, which in turn would enable WebRTC for all browsers in iOS, and also in Safari for desktop, natively. We think we could do this in less than 3 months.
Frankly, we are open to talk with Apple to help them implement WebRTC … We think we could do this in less than 3 months.
webrtcHacks: Do you intend to maintain this project?
Alex: Yes! Until MSFT and Apple deliver a native implementation.
webrtcHacks: Do you have a roadmap for this project then? What does it look like?
Alex: Yes, and it’s very simple:
- Add the data channel component, once we’re done with it on iOS
- Integrate all feedback from users, especially web developers, to cover as many use cases as possible
- Continue to keep the plugin as generic as possible, and as easy to use as possible, so that the lack of official support from MSFT or Apple will not impact the capacity of web developers to come up with great apps to illustrate what can be done with WebRTC
- Do the heavy lifting of staying close to the reference code, testing, releasing and hosting
- Wait for MS and Apple to deliver, and close the project
webrtcHacks: What happens when Microsoft starts supporting ORTC?
Alex: That’s a great question. We are part of the W3C ORTC CG, so we follow the group with a lot of interest. We are a little less active there, and that’s mainly because we like what we see. And, the most important actors of WebRTC 1.0 (Google, Mozilla) are also involved with ORTC.
It’s very clear to us that ORTC is not in competition with WebRTC at all. Instead, ORTC 1.0 aims to be at feature parity with WebRTC 1.0, while preparing for the future, and more advanced use cases – multicast, simulcast, layered codecs.. It also aims at decoupling all the different objects that are all hidden within a PeerConnection today, and their parameters.
ORTC also depends on part of WebRTC – for example, the MediaStreams. I do not see any reason why MediaStreams, getUserMedia, and the capacity to use a MediaStream as a source for a <video> or <audio> element is not implemented yet in IE. There was a plug-in providing a msGetUserMedia provided on the html5 labs some time ago, but it still hasn’t made it into IE. I might have missed something, as I haven’t actually had the time to check the latest ORTC implementation that MS announced a few days back. It would still be a plugin anyway.
It’s also funny to draw the parallel: both WebRTC and ORTC are enabled through a plugin in IE today. Except that, ORTC is not supported anywhere else.
webrtcHacks: I am assuming you have not had time to do much testing? Is that in the plans?
Alex: We actually did. We tested on all the references tests, including appRTC, and on our infrastructure.
Bistri, who has a great scalable platform and with whom we have great relationship went ahead and tried to integrate the very first alpha versions. It took courage, and we’ll never thank them enough for all the invaluable feedback they gave us. They managed to have their SDK support Safari and IE for basic calls within two days, and the more complex operations within a couple more days. We plan to jointly issue statistics to show the traction – number of downloads for example – and the change in usage pattern.
All that being said, we cannot test all the possible use case out there. That’s why we pledge to be very reactive to any dev that would bump into problems, and release very often. For as long as the alpha testing was going on, we managed daily releases. We should shave an auto-update feature in within this week to make it even easier to users. jsSIP’s lead developer Inaki Ibanez [and webrtcHacks guest author] already send us interesting feedback last night.
https://www.youtube.com/watch?v=GBKivqULmc8
webrtcHacks: Do you think this will hold up in a large enterprise environment?
Alex: We’re not afraid about the “large” part, a little bit more about the “enterprise network” part. But there is no additional problem you would have using our plugin than using native WebRTC as far as connection, firewall penetration, NAT traversal, … are concerned, and there are solutions out there already that handle that.
Our goal is to remove the “what about IE and safari” question from the Devs and Investors’ table long enough for a native implementation to land.
webrtcHacks: Where can our readers find out more?
Alex: Well, we’re very R&D oriented, so we prefer to spend time coding than writing blogs and issuing Press Releases. I’ll be the first thing to admit that we could improve on that. Of course you can check our website.
For the plugin, we have a specific site to support that: https://temasys.atlassian.net/wiki/display/TWPP/WebRTC+Plugins
Other than that, if you’re in Asia, or if you want to enjoy a never ending summer, come down see us in Singapore. We will be in the United States for most of June 2014 for our bi-annual pilgrimage to the WebRTC world Expo in Atlanta. I’ll be speaking at the WebRTC summit in NYC the week before Atlanta We’ll also be at the Chris and Tsahi show just after google I/O in SF.
Come meet us! We also accept donations in form of lattes, biscuits, stickers for our laptops, and all other awesome gadgets. 🙂 If you have written a book about WebRTC, we’d also love to have a signed copy. We also have a contest about who is going to get the bigger number of selfies and picture taken and shared on twitter. Game On.
If you can’t meet me in person you can follow me @agouaillard.
{“interviewer”, “chad“}
{“interviewee”, “Alex Gouaillard“}
Leave a Reply