Thursday, May 16, 2013

Google Hangouts testing WebRTC-based, pluginless implementation?

A sharp-eyed Toby Allen recently brought the following code to my attention:

Qg.prototype.init=function(a,b,c,d){"pi1");var e=window.location.href.match(/.*[?&]mods=([^&]*).*/);if(e=(e==m||2>e.length?0:/\bpluginless\b/.test(e[1]))||Z(S.Xd)){t:{var e=new Ad(Uc(this.e.l).location),f;f=e.K.get("lantern");if(f!=m&&(f=Number(f),Ka(Og,f))){e=f;break t}!Fc||!(0<=ta(dd,26))||webkitRTCPeerConnection==m?e=-1:(Pg.da()?(f=Pg.get("mloo"),f=f!=m&&"true"==f):f=q,e=f?-3:0==e.hb.lastIndexOf("/hangouts/_/present",0)?-4:1)}e=1==e}e?Rg(this,q):Sg(this,a,b,c,d)};

That's an excerpt from the Google Hangouts javascript code. It's a bit obfuscated (either by design; or, more likely, because it's the output of another tool), and I haven't taken the time to fully dissect it. But the gist of the code appears to be to test for the presence of a "mods=pluginless" string in the URL; and, if one is present, to check whether the browser supports the use of WebRTC's RTCPeerConnection API (or, at least, Google's prefixed version of it). It then looks like it calls one of two different initialization functions based on whether such support is present.

Alas, with this preliminary analysis, I couldn't get Hangouts to do anything that looked plugin-free, even on a recent copy of Chrome Canary. But it's pretty clear that the Hangouts team has started playing around with a WebRTC-based implementation.

The downside is that they're checking for Chrome's specific prefixed version of RTCPeerConnection rather than attempting to use a polyfill like most WebRTC demos on the web nowadays. So it appears that this functionality, when it's deployed, is most likely going to be Chrome-only -- at least, initially.

Tuesday, May 7, 2013

WebRTC: Welcome to the party! Please watch your head.

This is a republication of my section of a blog post from the Mozilla hacks blog.
About three years ago, my dear friend and VoIP visionary Henry Sinnreich spent some time over lunch trying to convince me that the real future of communications lay in the ability to make voice and video calls directly from the ubiquitous web browser. I can still envision him enthusiastically waving his smartphone around, emphasizing how pervasive web browsers had become. My response was that his proposal would require unprecedented cooperation between the IETF and W3C to make happen, and that it would demand a huge effort and commitment from the major browser vendors. In short: it’s a beautiful vision, but Herculean in scope.

Then, something amazing happened.

Over the course of 2011, the groundwork for exactly such IETF/W3C collaboration was put in place, and a broad technical framework was designed. During 2012, Google and Mozilla began work in earnest to implement towards the developing standard.

Last November, San Francisco hosted the first WebRTC expo. The opening keynote was packed to capacity, standing room only, with people spilling out into the hallway. During the following two days, we saw countless demos of nascent WebRTC services, and saw dozens of companies committed to working with the WebRTC ecosystem. David Jodoin shared with us the staggering fact that half of the ten largest US banks are already planning their WebRTC strategy.

And in February, Mozilla and Google drove the golden spike into the WebRTC railroad by demonstrating a real time video call between Firefox and Chrome.

With that milestone, it’s tempting to view WebRTC as “almost done,” and easy to imagine that we’re just sanding down the rough edges right now. As much as I’d love that to be the case, there’s still a lot of work to be done.

Last February in Boston, we had a joint interim meeting for the various standards working groups who are contributing to the WebRTC effort. Topics included issues ranging from the calling conventions of the WebRTC javascript APIs to the structure of how to signal multiple video streams – things that will be important for wide adoption of the standard. I’m not saying that the WebRTC standards effort is struggling. Having spent the past 16 years working on standards, I’m can assure you that this pace of development is perfectly normal and expected for a technology this ambitious. What I am saying is that the specification of something this big, something this important, and something with this many stakeholders takes a long time.

Even if the standards work were complete today, the magnitude of what WebRTC is doing will take a long time to get implemented, to get debugged, to get right. Our golden spike interop moment took substantial work on both sides, and revealed a lot of shortcomings in both implementations. Last February also marked the advent of SIPit 30, which included the first actual WebRTC interop testing event. This testing predictably turned up several new bugs (both in our implementation as well as others’), on top of those limitations that we already knew about.

When you add in all the features that I know neither Mozilla nor Google has begun work on, all the features that aren’t even specified yet, there’s easily a year of work left before we can start putting the polish on WebRTC.

We’re furiously building the future of communications on the Internet, and it’s difficult not to be excited by the opportunities afforded by this technology. I couldn’t be more pleased by the warm reception that WebRTC has received. But we all need to keep in mind that this is still very much a work in progress.

So, please, come in, look around, and play around with what we’re doing. But don’t expect everything to be sleek and finished yet. While we are doing our best to limit how the changing standards impact application developers and users, there will be inevitable changes as the specifications evolve and as we learn more about what works best. We’ll keep you up to date with those changes on the Hacks blog and try to minimize their impact, but I fully expect application developers to have to make tweaks and adjustments as the platform evolves. Expect us to take us a few versions to get voice and video quality to a point that we’re all actually happy about. Most importantly, understand that no one’s implementation is going to completely match the rapidly evolving W3C specifications for quite a while.

I’m sure we all want 2013 to be “The Year of WebRTC,” as some have already crowned it. And for early adopters, this is absolutely the time to be playing around with what’s possible, figuring out what doesn’t quite work the way you expect, and — above all — providing feedback to us so we can improve our implementation and improve the developing standards.

As long as you’re in a position to deal with minor disruptions and changes; if you can handle things not quite working as described; if you are ready to roll up your sleeves and influence the direction WebRTC is going, then we’re ready for you. Bring your hard hat, and keep the lines of communication open.

For those of you looking to deploy paid services, reliable channels to manage your customer relationships, mission critical applications: we want your feedback too, but temper your launch plans. I expect that we’ll have a stable platform that’s well and truly open for business some time next year.
Credits: Original hardhat image from; Anthony Wing Kosner first applied the “golden spike” analogy to WebRTC interop.