No Jitter is part of the Informa Tech Division of Informa PLC


WebRTC Is Not Losing Steam

Recently, some industry commentators have been writing off WebRTC. Here at No Jitter, analyst Zeus Kerravala claims that "WebRTC is losing steam." At TalkingPointz, analyst Dave Michels complains that "WebRTC is a distraction," and exhorts his readers to go out and buy a tried-and-tested solution. Seizing on this, Todd Carothers, EVP of marketing and products at CounterPath -- in an otherwise measured blog post -- argues that "WebRTC applications are restrictive in terms of the capabilities that can be offered as a true unified communications solution," and holds up his company's SIP-based VoIP products for consideration instead.

As someone who has lived and breathed WebRTC for the last three years (and SIP for the decade before that), I can understand a measure of skepticism over a technology being ready for prime time. But I also feel it necessary to point out where WebRTC is having success, and to combat some of the misconceptions.

Misconception: "You can't deploy WebRTC until the majority of browsers support it."
The main complaint about WebRTC is that browser support is incomplete, and so you can't deploy it on your company's website. Think of the poor Internet Explorer and Safari users! It would be so mean to make them use Chrome or Firefox instead! And yet this is what Facebook does when you try to make a video call in Safari:


As for Apple and Microsoft, we know Apple is working to add WebRTC to Safari, and Microsoft has been public about its implementation plans for WebRTC in the new Edge browser. In short, four of the five main desktop browsers (all except Internet Explorer) will soon be covered.

Misconception: "WebRTC is unsuitable for mobile."
It may sound surprising, but mobile is where WebRTC has really taken off. The Mayday help function on Amazon's Kindle Fire tablet uses it. Facebook Messenger uses it. Amex's iPad app uses it. As I explained in a previous No Jitter post, a WebRTC media engine powers the real-time parts of these apps, using the same on-the-wire potocols as the browser implementation (read "Why Use WebRTC?").

The complaint here is that you actually have to download an app, despite the fact that WebRTC promised us a download-free experience. Downloading an app? Oh, the horror of it!

The sad truth is that so many apps, particularly in banking, insurance and travel, could benefit from WebRTC. Most simply launch the mobile phone's dialer when you want to talk to a customer service agent, dumping you into IVR hell. "Please enter your account number and PIN." Oh wait, I'll have to look up my account number in the app -- but I can't use the app and the dialer at the same time! Wouldn't it be such a better experience if I could connect directly to a human, who already knows who I am, because the app itself already authenticated me?

Misconception: "WebRTC is a risky technology."
The premise here is you have to rely on Google or Mozilla to fix bugs in the underlying technology, and they will do so at their leisure. The alternative, presumably, is to buy a commercially supported product. As always, you have to balance the risk of using a piece of free software against the benefits. I think it's reasonable to say that the risk of something serious not being fixed is inversely proportional to the size of the user base, and Chrome and Firefox have very large user bases indeed.

And bugs, irrespective of whether the software is paid for or free, are a fact of life. Heck, I've even worked for companies that have closed bug reports with the notation, "Design intent; no plans to fix." If that happens to be in proprietary software that you can't touch, that's just too bad.

Misconception: "You will need a gateway for legacy interoperability."
In a world in which we use SIP to interwork with existing systems -- PBXs, media servers, and IP Multimedia Subsystem networks -- this is certainly true. We can even run SIP in a Web browser, by transporting it over the WebSocket protocol, and you can find a number of implementations in JavaScript. Even so, this usually means grafting on a Web server and modifying the SIP stack of the legacy systems in question so that they will actually work... not to mention hardening them against Internet-borne attacks. (Been there, done that, got the T-shirt.)

All that is very well, but interoperability with legacy systems is not necessarily at the heart of an application. If you don't need to build out a SIP-based infrastructure, why would you? Session border controllers and well-supported SIP application servers do not come cheap, and require expertise to run.

Here are a few examples where legacy interoperability is not needed, or is a secondary concern:

And if you need SIP access, then you indeed can find a gateway for that. If you are looking at using a platform-as-a-service (PaaS) provider on which to build your real-time app, then you should check what each supports. (Surprisingly, some WebRTC PaaS vendors don't support SIP.)

Concluding Thoughts
It would be foolish to pretend that WebRTC is a plug-and-play technology, as it is evidently quite raw and still evolving. To name some of the issues, browsers behave differently, getting NAT and firewall traversal to perform efficiently can be a challenge, and patent-related shadows hang over the choice for the next generation of bandwidth-efficient video codecs. Solutions architects and developers who understand these things do not grow on trees, so the hesitancy to move forward with promising projects is understandable.

It is easy to become disillusioned by the hype surrounding a promising new technology, when it does not emerge fully formed, like Venus on the half shell. But just try to remember where we were, just three years into SIP. H.323, anyone?