This article originally appeared on the VoIP & Gadgets Blog
WebRTC holds a lot of promise, and with the buzz surrounding WebRTC beginning to reach a fever pitch, it's worth pointing out the challenges it also faces.
First, let's begin with the expectations set for WebRTC. At TMC's recent WebRTC Conference, a panel discussed how WebRTC has high expectations. The explanation was that WebRTC has very ambitious goals, aiming to become the de facto standard by which user’s voice and video chat with other Internet users. This has the developer community and techies like me very excited.
With all this excitement and optimism for WebRTC, the expectations are high - leaving the first implementation of WebRTC in browsers ripe for disappointment.
The various browser implementations of the current WebRTC specifications are the first go around with some of the implementations not even complete. For instance, Opera 12 currently only supports the getUserMedia WebRTC API leaving out two other important APIs - RTCPeerConnection, which enables peer-to-peer voice & video calls and RTCDataChannel, which enables peer-to-peer data transfer.
We have to remember, WebRTC started not long ago - back in May 2011, so it is very new. I'm reminded of how the VoIP SIP standard started and there was years of interoperability issues. Heck, SIP interoperability issues still crop up today from time-to-time. It wasn't that long ago that VoIP and video over IP was a nightmare to try and get to work through a firewall. You had to open various ports, or do static NATing just to get one device to work, but forget about dynamic port allocation to allow multiple VoIP devices to work. SIP-aware firewalls didn't exist. And who remembers the voice/video NAT-traversal issues that Skype became famous for solving? Skype just plain worked and through any firewall with no firewall configuration. Just install and then talk and video chat - simplicity at its best. Later standards like STUN and ICE solved the NAT traversal problem.
But now we're talking about a browser doing P2P voice and video communication and solving the NAT firewall traversal issues. Fortunately, the work has already been done, so it's just a matter of including the code into the browser. But it's worth noting how far we've come.
Another challenge with WebRTC is the unfortunate codec battle. Google, Mozilla and the W3C support VP8 mostly due to the fact that they believe the video codec should be royalty-free allowing developers to use WebRTC without having to pay license fees. Apple, Microsoft, and Cisco favor H.264 since it is more prevalent and currently many devices have H.264 optimized hardware for accelerated encoding/decoding. I'm not a codec licensing expert, but I'd assume if the operating system already has H.264 bundled and licensed/paid for (Windows 7/8, Mac OS, iOS, Android, etc.) then you don't have to pay an additional H.264 license fee if your WebRTC app makes use of it. Someone please chime in, in the comments if I am wrong. But if I'm right, then clearly H.264 is a better choice due to all the hardware optimized to offload from the main CPU when doing encoding/decoding of video.
I'll point out that Mozilla's Firefox for Android includes H.264 support even though they were reluctant since they had to pay a H.264 licensing fee. Google did announce that Chrome would drop its support for H.264 and concentrate on VP8, but Google never did remove H.264 from Chrome. Eighty percent of HTML5 video on the Web uses H.264, so I just don't see Google removing H.264 support. According to Ars Technica
, “the growth of mobile platforms made the demand for H.264 support even more acute: hardware acceleration of H.264 decompression is all but universal on mobile devices and taking advantage of this hardware support is essential for providing acceptable battery life.”
“These concerns led Mozilla to change its policy in March and start work on providing H.264 support in Firefox. The group is sidestepping the licensing concerns by taking advantage of the system frameworks provided on Android that expose the hardware accelerated H.264 features. By leaving the decoding up to the hardware, Mozilla also leaves the license costs up to the hardware suppliers.”
This seems to confirm my suspicions, that Google worrying about WebRTC developers having to pay H.264 royalty fees is unwarranted, but again if I am wrong, please post a comment on my blog post.
Let me add that at TMC's WebRTC Conference, the panel said some browsers will likely initially support both codecs to prevent any potential roadblocks in WebRTC adoption. Considering the main browsers that currently support WebRTC - Google, Mozilla, and Opera, favor VP8, it appears VP8 will be the default codec for now.
The other major challenge is where Microsoft and Apple stand in this. Back in August 2012, Microsoft and their Skype team of engineers announced their own proposal for plug-in-free real-time communication called "Customizable, Ubiquitous Real Time Communication over the Web" or for short - CU-RTC-Web. It was rejected by the W3C and Microsoft has been eerily quiet on WebRTC since then. Not good. Apple on the other hand has been quiet from the beginning. They haven't said anything about WebRTC, which is very disheartening when you consider the millions of iOS Safari users out there.
Yet another challenge is PSTN (mobile, landline, etc.) integration via WebRTC-to-SIP gateways. Already some solutions exist out there to bridge the WebRTC Internet world with the PSTN world, including Plivo. So this challenge is being addressed very quickly.
One last challenge is really more of a suggestion on my part to the WebRTC spec. I'd like to see support for screen sharing. Now, the Google Chrome team has said that they intend to support screen sharing according to their roadmap. I did read that you could write your own web camera driver, so that your local screen appears to the WebRTC getUserMedia() API as just another video source, but that would require a driver, which defeats the purpose of WebRTC's plug-in-less design. HTML5 Rocks offers a few methods, but they're hacks and are specific to Chrome-only.
The Chrome Team offers an experimental Tab Content Capture API that lets you capture and share the current tab being displayed. You can also read more about this here. Unfortunately, this API only shares your browser tab and not your entire desktop, which is limiting. Perhaps the browser is sandboxed from the operating system due to security concerns, though I don't see why a prompt "Allow Share Entire Desktop" wouldn't address this. The Google Chrome Team had this to say about the WebRTC Tab Content Capture API, "This API enables a special form of screen casting, but in which users are able to share the contents of a tab rather than sharing their entire desktop. This avoids a number of issues with desktop sharing, such as the presence of icons, taskbars, window chrome, pop-ups, and other elements that it is often not desirable (or in some cases, even embarrassing - e.g. when a new mail notification or IM shows up for all to see) to share."
Google tends to be Web-centric (Gmail, Chrome, YouTube, etc.) and this comment to me seems like Google dismisses the value of the local desktop. Sorry Google, but not everything runs in the Web, as much as you would like it to.
I'm honestly not sure why full desktop sharing isn't being considered. This means users will be forced to still use WebEx, GoToMeeting, VNC, etc. if they want full collaboration. Some of these screen sharing apps aren't available on iOS, Android, or Windows Phone 8, so yet another stumbling block for easy browser-based communications.
The W3C Last Call Working Draft is expected in Q3 2013, with the final WebRTC specification expected to be standardized in 2014. So we're still a ways off from WebRTC becoming finalized, but as with anything this exciting in technology, developers are itching to write WebRTC applications today. Be on the look out to see if everything goes as expected or not, and make sure you attend the WebRTC Conference & Expo taking place June 25-27th in Atlanta.
Edited by Stefania Viscusi