I recently got into some interesting conversations about WebRTC. Not even the exasperated "I know when I see it" approach worked well.
Let's start with the obvious - just check the standard. Well, there is no standard. The IETF and W3C groups that are working to approve the WebRTC standard have not yet agreed on it. Fierce debate about the technological components still continues.
Despite this lack of formal ratification, there are plenty of WebRTC solutions already available. This is in part because Google proceeded with its notion of WebRTC. Google released its libraries of codecs and transports that ship alongside their flavor of WebRTC support within the Chrome browser. A pre-WebRTC ecosystem is emerging with multiple conferences, vendors, and applications.
These applications are modeled after a proposed WebRTC standard. Now without looking, you might be able to guess some of the components in the draft - such as Opus, VP8, NAT traversal libraries, and so on. Oops, they aren't actually there. Proposed standards, or drafts, are actually more of description - they don't generally include things like specific technologies or sample code.
Specific technical components get covered in the Working Group meetings. Opus was selected for WebRTC audio. The most popular codec associated with WebRTC is the video codec VP8, but its inclusion in WebRTC is greatly exaggerated - it's one of the biggest areas of the standards debate. VP8 was included in Google's WebRTC free library. So, use of VP8 is clearly not WebRTC compliant. Even Google seems to have hedged its bet by recently accommodating Cisco's open H.264 in its WebRTC Library.
Another common test for WebRTC compliance is Chrome compatibility. Google Chrome was the first browser to support WebRTC, and most of the new applications rely on Chrome in order to be plugin-free. Other browsers that support WebRTC include Mozilla Firefox and Opera. These browsers use much of the same code, yet compatibility issues exist because Chrome has considerably more capability than what's specified in the WebRTC specification.
For example, the draft doesn't include "on the wire" signaling, but Chrome makes signaling capabilities available, likely to simplify development efforts. Technically, there is nothing wrong with this - the use of Google's options is not necessarily in conflict with the proposed standard. The problem is these capabilities do not exist in other browsers, further defeating browser-independence.
Google changed its own Hangouts service to be more in line with its view of WebRTC - it switched to the VP8 video codec and no longer requires a plugin in Chrome. However, Hangouts is not WebRTC compliant. It utilizes several non-compliant components, including SDES security descriptions and an older variant of ICE parameters. Evidently, Google determined the need for these technologies outweighed the benefits of WebRTC compliance.
Another point of confusion is whether or not WebRTC applications must run in a browser. Many people, and I was one of them, believed that WebRTC is a browser-based technology to enable real-time communications. In fact, the title of the specification is indeed, "WebRTC 1.0: Real-time Communication Between Browsers."
However, just a few lines below this title, in the abstract, it clarifies "to allow media to be sent to and received from another browser or device implementing the appropriate set of real-time protocols." Browser or device? WebRTC is a peer-to-peer technology that can run between browsers or other devices such as servers and even client applications.
Do WebRTC applications only run in browsers?
This question spawns some interesting debate. The majority of experts I've spoken to agree that WebRTC applications do not require a browser at all. While the browser was clearly a big part of the initial thrust of WebRTC, the promise of ubiquitous browser support seems distant at best. In addition to both Apple and Microsoft not incorporating WebRTC 1.0 into their browsers, there's the larger issue of delivering WebRTC to mobile devices that favor locally-installed applications.
Google recently released WebRTC libraries for iOS which has since enabled applications such as Gruveo to migrate from Flash to WebRTC. WebRTC Aficionado Tsahi Levent-Levi recently wrote: "Going mobile with WebRTC? You either need to accept the low reachability you will have, or port it and build an app for it. Both options are valid, and it really just depends on your use case." As a result, many developers are now turning to local clients to incorporate WebRTC elements into their applications - and completely skipping the browser.
So the draft specification isn't a good test for most of us. The browser-based strategy remains limited and incompatibilities are increasing. Even worse, WebRTC seems to be moving into the comfortable digs of OS-centric applications, potentially creating even more silos in the market.
WebRTC is clearly instigating innovation like no other technology in communications. The media engine, open source code, and access to a huge base of end users via select browsers create a fertile environment for new solutions. WebRTC applications will come in all sizes and shapes - some will tap into just specific components (such as the video codec) and some will leverage the full stack of optional capabilities within Chrome - most will likely sit somewhere in the middle with their own secret sauce such as signaling.
WebRTC was clearly over hyped as a cure-all, but now a more pragmatic approach is emerging. The fellows at Hookflash are intent on improving things by adding their own signaling (Open Peer) to the WebRTC conversation in an effort to bring Microsoft and Google together. But even if Microsoft and Google aligned, that still leaves the question of Apple.
The effort accompanies Hookflash's embrace of the Object RTC (ORTC) initiative, in which both Google and Microsoft are joining. "We won't be solving all WebRTC challenges with ORTC, but some of those issues seem more political in nature," says Erik Lagerway, Co-founder of Hookflash. "ORTC will make WebRTC more accessible for web developers, maybe as an evolution to WebRTC 1.0 and not as an alternative."
WebRTC is a set of real-time technologies that can be applied in a certain way, or not. The new types of applications include browser-based solutions and client-based applications with some or all, or more than all, components. WebRTC can be open or proprietary.
Ultimately, applications get consumed for their benefits, not their technology. It may not matter if it's a WebRTC application or not. "WebRTC really isn't just about technology," says Tsahi Levent-Levi. "It's always been more about the impact of free and open communications. WebRTC reduces friction and drives collaborative innovation. If the application delivers that, and couldn't have otherwise, then it's a WebRTC application."
Dave Michels is a Contributing Editor and Analyst at TalkingPointz.
Follow Dave Michels on Twitter and Google+!
@DaveMichels
Dave Michels on Google+
