WebRTC, what is it for?

Having attended the recent WebRTC Summit conference in London I’m still not sure of the role this technology will play in future services.

Within the operator community I see a couple of very polarised views. Firstly, all the core network people, well versed in the last decade of IMS justification, see this as an extension to their, for some, unfathomable world. Telling tales of how difficult transcoding is and how SIP and other protocols need to interact with each other. Maybe it can be linked to RCSe to justify the enormous expense (is the domain WebJOYN.com still available?).  At the other end of the spectrum product marketeers struggle with the usual questions of whether or not there is a demand and how to directly monetise the product which means that nothing will happen in that area!

All of this is irrelevant as the OTT players and the developer communities simply don’t care. They just want to know that a simple API will be made available by the operators, preferably as a community, and that it will reliably work every time. In addition, despite the fact that it was Google who first initiated the concept with its submission to the IETF in 2011, the Chrome browser upgrades often frustrate those working in the minutiae of the WebRTC world as they regularly fail to be backwards compatible for this service. Apparently, Firefox has similar issues.

Although a very unstable product and a lack of clarity of business case is a common situation for new technology, at times, it feels like WebRTC is an invention struggling to find a problem to solve. Most use cases involve video calls embedded in a browser. As a regular, several times a day, user of personal VC tools, I am not sure this is needed at all. I spend hours on Skype or within meetings via Bluejeans (with Skype plug-in) on my browsers (including Safari which is not WebRTC compatible). In my experience, I know in advance that a VC is arranged and I prepare my tools and environment accordingly. If I needed to download and install a plug-in for my browser then I do so. From a user perspective, the USP for WebRTC is that the plug-in is avoided but, in my experience, this is hardly a blocking issue.

Skype, and its Microsoft stablemate Lync, along with Apple’s FaceTime, will do fine for most people in consumer and enterprise domains.

The data channel has uses in the peer to peer file sharing space and those with a full dropbox or yet to discover mailbigfile.com could use this once the security and ID elements have been resolved. This is most simply shown by pipe.com who offer this free service to customers.

I do believe that WebRTC has a role to play in the wider Telco API world in that it is a useful tool to accompany other services. I see the ‘click to contact us’ use case to be the most useful as it is a spontaneous act so there is no time for a plug-in download. This will be especially powerful if combined with some sort of ID federation so that the customer care agent on the other end of the call does not need to ask your mother’s first pet’s maiden name and the PIN of your place of birth!

The main point, however, is that operators need to be in the game to influence it to their advantage. A lack of an obvious immediate direct revenue opportunity is not a reason to do nothing as the void will eventually be filled by some other OTT player taking a chance. The dumb pipe will become even dumber if they do nothing. Remember, it was Google whose open source project started this is in the first place.