Will WebRTC change the communications world? Since WebRTC is currently in a hype phase, I will take the contrarian position in this post, describing why WebRTC is not the Next Big Thing, and then take the pro-WebRTC view in a future post.
WebRTC, half of a job done well
WebRTC gets your voice and video up to (*any*) application. MediaStreams and the getUserMedia API provide a simple and standardized way for a browser to grab media and act on it, and that’s very powerful. Lots of functionality “moves” into the browser – the RTP stack and media codecs, firewall and NAT traversal mechanisms, signaling and media encryption functions. All goodness. However, the second half of the job is connecting two or more people/browsers/apps.
Houston, we have a problem
WebRTC took our video streams up to our respective browsers/apps. Now, how do we connect our browsers such that we can enjoy a video session? PeerConnection focuses on this inter-party voice and video communication aspect of WebRTC, but PeerConnection leaves too many key functions open or undefined. Each WebRTC app then needs to decide how to implement these functions (the positive view on this in a future pro-WebRTC post).
The list of critical functions that are largely undefined in PeerConnection include codecs, authentication, identity and routing. Undefined or loosely defined functions often result in islands because all the implementers then make their own choices, often choices that don’t end up playing nicely together. Video codecs are still not locked down. On the audio codec side, G.711 will be mandated, but the more interesting wide-band audio codecs will likely all be optional. Everything else – identity, authentication, privacy, routing, presence, QoE, TURN (or not), etc. – is left to the application implementer. PeerConnection will result in islands. Some attractive islands with cool beaches (functionality), but new islands aren’t the disruption that many WebRTC advocates are hoping for.
Part of each WebRTC island is floating in the SIP Ocean
PeerConnection uses a SIP SDP-like offer/answer protocol (ROAP). SIP SDP is not horrible but it is limited and doesn’t necessarily fit with more disruptive, interaction-based communications paradigms (always-on video sessions for example). This emulation of SIP SDP puts part of each WebRTC island into the SIP Ocean, and specific implementations may drag entire WebRTC islands into the SIP Ocean. There are good reasons for WebRTC/PeerConnection to leverage some SIP aspects, but WebRTC would be far more disruptive if it stepped completely into new waters. Data Channels – the part of WebRTC that focuses on peer-to-peer data sharing – also leverages PeerConnection (will discuss Data Channels in the pro-WebRTC post).
External WebRTC obstacles
The current communications landscape is riddled with WebRTC obstacles.
Microsoft and Apple
Microsoft IE and Apple Safari don’t have defined roadmaps to support WebRTC (IE can be hacked via Chrome Frame). Microsoft has vested interests – the leading enterprise communications UC client (Lync) and the leading consumer voice/video solution (Skype) – and in fact has proposed a WebRTC alternative, CU-RTC-Web, which is more robust or more complex than WebRTC, depending on your perspective. Apple has been quiet on WebRTC, keeps tight control of Apple platforms, and has treaded lightly in real-time communications, for example keeping Facetime relatively limited. Until Microsoft and/or Apple find business value in WebRTC, they are likely to be obstacles.
Mobile browsers are not committed to WebRTC, and aren’t as easily extended as their non-mobile OS browser cousins. While Google is one of the primary WebRTC drivers, that does not necessarily bode well for mobile in general since Google’s mobile competitors may respond with anti-WebRTC, or at least anti-Google-version-WebRTC stances. It will be interesting to see if Google drives WebRTC on Android and Chromium, and makes apps like Google Hangouts, Google Talk, and Google Chat be WebRTC “compliant”. Perhaps an Amazon, Samsung or Facebook type company will WebRTC enable their mobile apps, but that is more island-ish than the more pervasive and universal results that WebRTC advocates would like to see.
The old guard and the current dominant business model
Most traditional telcos are slow moving and have incredibly complex and inefficient ecosystems (that even they don’t completely understand) built around yesterday’s communications landscape. This applies to their business models, processes, systems and people. Telco ecosystems are therefore not easily changed, even with the best intentions, meaning even a “pro-WebRTC” telco is unlikely to move the needle, and may even slow progress if it bends WebRTC to fit the traditional telco model. However, some telcos do seem to understand the opportunity (see Telefonica’s acquisition of TokBox), and that is the first step in the process.
New guard “telcos”, for example Voxeo and Twilio, may be more interesting than the old world telcos, but I will save that discussion for the pro-WebRTC post. Any type of telco will need to move from the transaction-based paradigms and business models (calls made out of context of any process and billed per minute) of old-world communications to the interaction-based paradigm that we need to get to (our apps easily enable us to easily interact (including voice and video) whenever, wherever and however we wish to).
At the moment, WebRTC is really the getUserMedia API and MediaStreams. That’s powerful but not the disruption that most WebRTC folks are hoping for. Some of this is due to the construction of WebRTC itself, some of it is due to external factors. In combination, the result will be another good island, not a paradigm shift in of itself. I think communication is moving to islands with or without WebRTC, islands connected by each user (“Younified Communications“), but that is not what WebRTC’s strongest advocates would like to see.Google+