WebRTC is a cool technology, but there’s a lot to be done there before it can be commercialized.
I might have given the impression that WebRTC is here and that this means WebRTC is a done deal. You can start developing today and releasing a product to market next week.
Well… it doesn’t work like that.
The only thing out there running WebRTC today are demos. There’s a nice one from Voxeo. There’s a new service from TenHands. And the rest are just pure hacks.
There is a long way to go still.
I’ve written on NoJitter about the current (and future) browser support of WebRTC.
It is far from being a done deal – the fat lady isn’t singing yet, so there’s time still to fool around with other “legacy” technologies…
Here are a few glimpses as to what is still missing.
Media Relay
Media relay is required because of NATs and firewalls around the internet. These make connecting direct video hard or even impossible. To that end, there’s a protocol called TURN.
How’s Google Chrome fairing with TURN?
We will also support TURN servers to allow connections through tougher firewalls, where relaying and encapsulation are needed. Exactly what type of TURN will be supported is TBD.
Oops. Probably this is why TenHands are still using a browser plugin for their service instead of native browser support:
Our requirement is more to do with what the underlying implementation than the JS API. We need TURN capability in the browser and made changes to support the same.
Which Codecs?
While Google’s own plans with the codecs they are going to use are closed, there are those who would like to see other solutions there.
An earlier draft of the IETF tried to push H.264 into WebRTC for video coding, only to be dropped out at a later draft:
If the MPEG-LA issues an intent to offer H.264 baseline profile on a royalty free basis for use in browsers before March 15, 2012, then the REQUIRED video codecs will be H.264 baseline. If this does not happen by that the date, then the REQUIRED video codec will be VP8.
Well… MPEG-LA didn’t comply, and the IETF guys have switched back to VP8. At least for now. This will hinder their adoption when it comes to supporting higher resolutions or extending battery life on mobile devices.
As for audio, just look at the same Google Chrome blog post from above. In the comments, people are asking for support of Opus:
Any consideration for adding Opus support for audio as well? The technology looks extremely promising.
I see Firefox is already working on getting it implemented (in both <audio> and for WebRTC use).
Specifications
WebRTC is relatively new. While it is part of HTML5, it has a long way to go until its APIs and functionality get stabilized. The IETF draft of codec requirements is one side of the story. The same goes for signaling around it, where a new JSEP protocol is being defined.
These things take time. We will see proof of concepts, demos and even products launch to market with support for WebRTC. But until time passes and things get stabilized it is going to be messy.
Adoption
Then there’s the adoption part.
While WebRTC doesn’t really require anyone to install anything new, or for people to connect their existing systems, it does have this nagging requirement of the browsers to support them. Apple isn’t going to be any help here, which means that at least on their systems, WebRTC will be a second class citizen – living either as a plugin browser on the Mac or as part of an SDK in an AppStore application for iOS.
WebRTC will be inside plugins for a long time.
–
The fat lady is still waiting. Beefing up with the missing pieces of the WebRTC puzzle. Biding her time.
She will sing eventually. And the song will be a WebRTC one.