WebRTC started as an initiative in Google to take advantage of the assets in GIPS and On2 Technologies (News - Alert). Both of them had great intellectual property in the realm of rethought codec solutions. The overall scheme was to have an alternative to Microsoft’s Silverlight and other intellectual property that impacted their video strategy. Overall the strategy was to bring to the web a rich communication solution that was different from the phone service.
Well, somewhere along the way the battlefront went to wireless and pitted H.264 against ViPer.
The funny part about this battle is that it has lots of interesting nuances that never really came to light. For example, the carriers really like H.264 because they have paid for it already; however, the place where video is being used, Facetime, is an over-the-top H.264 service that does not involve the carriers. Thus the service that in the carriers’ world would be associated (and cross-elastic) with voice minutes is part of the megabits pricing.
Further complicating the strange and wonderful relationship is the early adoption by the session controller companies of WebRTC, making it a gateway protocol with transcoding being a key feature. This tied the web part of WebRTC to the phone number, which was a lot like Gulliver being captured by the Lilliputians. What was a very open and freeing idea became an extension of a 12-button sub intelligent plain old telephone set.
Note: I want to say that there is an opportunity to make the POTS phone rich with WebRTC, but it is probably only for the companies offering primary service. However, POTS is in twilight, so the question has to be: What is the implication of all these forces when it comes to wireless?
I am going to suggest that there are two good strategies when looking at WebRTC with wireless and then suggest that eventually the two camps will have to converge, but not until the battle is lost or won between the over-the-top and carrier/device call control camp.
I think the first implication is that call control should not be the focus of any app developer. Delivering a solution that in effect is trying to be an over-the-top phone has been done. I am fine with companies like 8x8, Microsoft/Skype (News - Alert), Vonage, and other softphone junkies extending with WebRTC, but that in the end is table stakes and should be grabbed at the app store.
WebRTC opens up the communications experience to web feature interactions. Companies can build an entire scripting tool for a web attendant that would be far more brilliant than the chat services currently offered. Developers can plug into a cloud speech recognition service. They can become more contextually aware than anything the carrier or the device manufacturer can connect to general social networks. In other words, whatever you can think you can do on the web you can expand with WebRTC. Probably the most important aspect of that is to expand the navigation capability of the smartphone’s small screen. Enabling voice command taking us beyond Siri’s “This is what I found on the web” and reading with the intent of manipulation would be huge.
On the other side of the equation, the carriers and device manufacturers that have direct access to call control can start enabling a different experience for the address book. Just like Apple distinguishes SMS that is from an iPhone (News - Alert) from those that are not, a carrier can expand the codec option for video and the ability to socialize a call to the subscriber. This would make for distinct services that go beyond the sad address book experience we have today.
Ultimately, the nature of human interaction is going to force the over-the-top and the call control clans to find interfaces that interconnect, be it via a restful API or a session controller API.
In the meantime, your wireless device is the subject of a clash between titans and startups. The web is full of startup successes; let’s hope the WebRTC brings communication rich successes to your smartphone in near real time.
Edited by Stefania Viscusi