WebRTC is a Distraction

March 03, 2016 by Dave Michels

This just in from the WebRTC front: It still sucks.

Next week is Enterprise Connect and I expect, once again, that there will be a WebRTC love-in. There will be some really smart folks explaining its virtues, and some killer solutions that demonstrate how effective and seamless the technology can be.

Don’t be fooled. WebRTC at best is a fantasy that may indeed someday come true, but at worst it’s a dangerous distraction that can waste a ton of money, cost customers, and squander opportunities.

I get the love-in part. Who wouldn’t love WebRTC? It’s free, and I for one love free stuff. Even better, it is free and valuable. Google bought much of the IP and then gifted it to be open.

It’s also logical. I remember the first time I saw the Netscape browser. I can’t recall my initial exact thoughts, but it was probably something like “wow, cool – too bad it’s so limited.” Over the decades, the browser has evolved to become my primary application. It supports sound, HD video, PDFs, and serves as a portal to the world. Why not interactive, real-time communications?

My problem with WebRTC is I’m tired of waiting. Even worse, it’s taken so long that I’m not sure I even need it any more. It’s like a late pizza that arrives after settling for a box of microwaved Hot Pockets.

WebRTC is something that 1) we should stop waiting for and 2) celebrate when it eventually arrives. These are not contradictions, here’s why:

Limited Support. The true power of WebRTC lies in ubiquity. The idea that every browser supports real-time communications is powerful. It means, write once-deploy many. As of today, most browsers do not support WebRTC. Microsoft is working at it, but don’t hold your breath for Apple. Someday this may change – and someday I will celebrate WebRTC. Today it’s a reasonable solution for internal intranets, but then so is deploying apps or plugins.
Mobile is what really matters. I recently got chastised for sending an email instead of a text. We’ve been talking “mobile-first” for sometime now. WebRTC is optimized for the desktop. Mobile devices that leverage WebRTC tech use apps – not browsers. Since the WebRTC mobile SDKs require apps and provide limited support and quality why bother?
Why Bother? WebRTC helped Google legitimize Chrome while simultaneously threatening Skype. Those have largely played out now which possibly explains why Google seems to have lost interest. What is the differentiated value that WebRTC brings moving forward?
WebRTC is Dangerous. It’s an Ikea world built on pre-made SDKs, APIs, and code snippets. The problem is what to do when there’s a problem. Consider Heartbleed – everyone re-used the same code – and everyone had the same problem. It’s very hard to fix something that 1) you don’t understand 2) you don’t control. If you are building a strategic product – consider building it.

I am not convinced WebRTC has a place (today) in communications apps. It does offer a simple means of adding communications to other apps. So if lowest common denominator comms works for your business and the users are known to use a supported browser – go for it.

The other options are to make yourself comfortable and enjoy the wait for the value WebRTC will someday deliver, OR license/embed (or create) real-time technologies that work today.

By Dave Michels

Dave is an independent analyst and founder of TalkingPointz which is focused on enterprise communications. In addition to this (free and paid) content on TalkingPointz, he contributes to industry sites, can be found at major industry events, and provides advisory services to vendors and financial analysts.

Look ma, no ads!

Admit it! You just can’t look away. Yet, there’s so much more.

Become a subscriber to TalkingPointz for access to reports and premium posts.

There are several ways to stay informed:

Visit this site regularly.
Receive new posts in your email once a week.
Become an Insider or All Access Subscriber for alerts and access to uncensored content.

Become a Member from $49 / month

TalkingHeadz Podcast

The TalkingHeadz podcasts are @DaveMichels and @EvanKirstel chatting with interesting guests. These are unsponsored and unscripted for your enjoyment. You can subscribe on most podcast apps including iTunes.

Listen on iTunes

Podcast

TalkingHeadz with Brad Hintze of Crestron

April 10, 2023

Multi-camera video is best demonstrated in large conference rooms, and that can be a challenge in an expo hall. Crestron solved it: We’re going to need a bigger booth. I experienced Crestron’s 1 Beyond experience in an expo booth with…

Discussion

Sergio March 6, 2016

Give this man a cookie. Wasted a ton of hours on getting the browser, pbx, ice, srtp, dtls, audio device setup (people use headsets…..) and no, device selection doesn’t work properly in Chrom(ium)…. It just still sucks….

Reply
Francis Kurupacheril March 11, 2016

As with all technologies, the ‘standards’ bodies want to standardize. The vendors delay the standardization until after they can make their walled gardens. When the releases happen ( standards and products ), everyone benefits except the end customer. WebRTC will go the same way.

Reply
ckoehncke March 13, 2016

Dave, I can’t let you slide past me on this! 🙂 However your very article reminds me a time not too long ago when we had similar words about VoIP. It didn’t work. The standards weren’t complete. The Internet wasn’t ready. Corp networks couldn’t handle the traffic. The voice quality was bad. God help you if you dialed E911. Users had to know 100 parameters to configure. Simple things like NAT and firewalls confounded applications. Users were worried about security and telephone companies didn’t like it. It was all just a bad idea.

All technologies take a long time and we’re all similarly impatient. However, we can’t get there until we cross the hurdles which requires time, technology and argument.

WebRTC hasn’t yet hit mobile because we are stuck talking about “downloaded” applications. I fathom in 10 years we’ll all have a good laugh about how we used to download applications into our phones. To some degree, the Internet hasn’t hit mobile phones yet.

The reality is WebRTC will ride along into mobile as the entire notion of “browsing” gives way to a new era of how we consume information and application in the Internet. Here WebRTC won’t be more than a simple ‘bolt’ in this new framework.

Reply
1. Dave Michels March 13, 2016
  
  I agree with everything you say.
  
  I am not opposed to WebRTC long term or even time spent on progressing it through standards. I am opposed to building commercial grade apps with it today – it’s a distraction. It is not ready, not complete, and offers no benefits over more proven approaches. It’s been 5 years of ‘we are almost there’ and when v1 finally gets approved ‘next year’ it still won’t be enough as the next generation drafts are already addressing today’s needs. Organizations need to stop wasting their time with WebRTC solutions and focus on helping people effectively communicate today.
  
  Reply
Hugh Isaacs II March 14, 2016

1) Limited support doesn’t matter. That’ll change and WebRTC being a standard and not a specific technology means developers can code around that limitation (native apps, plugins, etc…). Shoot there are already several browser plugins for Safari and Internet Explorer to support WebRTC (two notable ones being the Temasys WebRTC plugin and WebRTC-Everywhere).

2) “Since the WebRTC mobile SDKs require apps and provide limited support and quality why bother?”
This argument lacks detail so I won’t entertain it too much but webrtc.org has full Android and iOS SDKs, that don’t “provide limited support and quality”, they provide full support and quality.

Also Chrome, Opera and Firefox for Android all support WebRTC.

3) “Google seems to have lost interest. What is the differentiated value that WebRTC brings moving forward?”
Google hasn’t lost interest, seeing as they keep updating WebRTC support in Chrome and keep building out the spec.

Now differentiated value? Well there’s plugin free voice and video chat which is bigger than it might seem, since this means there’s a guaranteed communication point for all users of supporting browsers (basically everything except for Safari and IE), basically turning the web browser into something like the chat app Pidgin but for voice and video chat.

But what I think it’s far more important regarding WebRTC is a completely standardized spec for peer to peer communication that just happens to have web browsers as it’s main target.

We now have projects and products like PeerCDN, WebTorrent, and more that are helping further decentralize the web by freeing it from servers, domain names and static IPs, where in the past these concepts were basically pipe dreams as it was difficult to get widespread adoption. In the future your very own blog might not even be hosted on an actual server thanks to WebRTC.

4) “WebRTC is Dangerous. It’s an Ikea world built on pre-made SDKs, APIs, and code snippets. The problem is what to do when there’s a problem. Consider Heartbleed – everyone re-used the same code – and everyone had the same problem.”

This isn’t actually a problem. WebRTC isn’t OpenSSL, it’s a standard not a technology, just as SSL and TLS are standards and OpenSSL is one implementation of that.

When Heartbleed happened, not everyone providing TLS or SSL certificates were affected, only those using OpenSSL (which were a lot sadly, but that’s a different problem in itself).

Best example is Firefox and Chrome don’t use the same WebRTC software, they’re just compatible because they follow the guidelines.

Reply
Robert Welbourn March 15, 2016

Dave — A distraction from what? If I want to build contextualized, real-time communications into a web portal or mobile app, what else do you suggest I use? Someone’s VoIP client SDK? How’s that going to work in a web browser, when the ability to embed plugins is being increasingly restricted, and it’s a pain in the ass to get users to download plugins anyway?

On your specific points:

1. Limited support. Partially true. Right now we’re waiting for the notoriously opaque Apple to join the browser party, but there’s evidence (in the form of a job advert) that they’re working on adding WebRTC to Safari. In the meantime, there’s Chrome, Firefox, Opera and Edge that you can use.

2. Mobile is what really matters. Well, yes. If I may adapt Bill Clinton’s phrase, “It’s all about mobile, stupid!” I can get a nice, free RTC engine from the Chromium project and build it into my Android and iOS apps. And guess what? It uses the same on-the-wire protocols as my web app, so I can use the same infrastructure, the same web portal code, and so on. So it’s built into an app, and not a mobile browser — so what? It works for Facebook Messenger and Amazon Mayday — you call those failures?

3. Why bother? Oh, I don’t know: making contact centers significantly more productive by pre-authenticating the caller and getting rid of IVR hell, perhaps?

4. WebRTC is dangerous. To whom? Vendors of VoIP SDKs, perhaps? No wonder Counterpath tweeted out an approving reference to your post!

Reply
1. Dave Michels March 15, 2016
  
  Thanks for commenting Robert.
  I get the dream, but don’t confuse that with reality (today). Do you really think Webrtc offers an upgrade for call centers over the IVR? I get that IVRs are frustrating, but seriously – 50% or more of the customers likely can’t do WebRTC. Then a high percentage of those that can won’t have the right A/V settings (authorize mic in the browser, go to system settings to select sound – oops not that mic the other mic). This is why it’s a distraction – call centers that want to deliver superior experiences should use proven tech today – the simplest is click to have someone call you. Other options are comms enabled apps or even just a telephone number with an intelligent IVR. Amazon is investing in WebRTC heavily, but their customer service uses click to have someone call.
  
  WebRTC today is fine for internal deployments because you can control the settings and clients – but you can also download apps that offer richer experiences.
  
  Someday all browsers will be real-time capable by WebRTC (v3) or other technologies. There’s tremendous progress happening and that’s a great thing. It’s just not there today. If browser based comms is a requirement for some reason – there are ways to do it, but why? Why bother implementing an incomplete tech that isn’t widely supported? Fine wines take time – so do standards and ubiquitous adoption. ORTC is already effectively version 2 or 1.1, but 1.0 still isn’t even approved. It will probably be the third iteration that’s ready for prime time, and that is years away.
  
  I think Cisco Spark is a great example of how to do WebRTC. It works great with WebRTC in FireFox only. Since that isn’t sufficient for a lot of enterprises they also offer a client. The client offers a richer experience due to gaps in WebRTC. The solution is architected for the future with WebRTC in mind (and available today for those that want it), but delivered today in a client for those that need robust comms now. Theoretically, when WebRTC is ready, so will be Spark.
  
  Reply
  1. Robert Welbourn March 15, 2016
    
    Dave, let me give you a couple of examples where WebRTC can help call centers today, based on my own experience as someone who has worked with the technology.
    
    1. I have the Progressive Insurance app on my mobile phone. Recently, I wanted to cancel the insurance on one of the family’s vehicles. But the app wouldn’t let me do this; it popped up a message saying “To complete this transaction, please call 888-xxx-xxxx. You will need proof from the RMV that you have canceled your registration or returned your license plates.” It even offered to dial the number for me, using the iPhone’s native dialer.
    
    However, all context was lost. I was dumped into an IVR, asked to input my policy number and the last four digits of my social security number, put on hold, asked by the agent to verify my identity and why I was calling. What’s worse, is that I couldn’t use the app to look up my policy number while I was using the phone’s dialer! I had to cancel the call, go back to the app, write down the policy number on a piece of paper, and call again. And this is supposed to be a good customer experience?
    
    What should have happened is that the app should have included its own RTC client, and that my identity and the call context should have been delivered straight to the agent. If I had been in an accident, I should have been able to use the phone’s camera to transmit video of the scene,
    
    By all means argue that callback technology would do the job. However, callback is not as simple as some make it out to be. There’s usually an IVR as part of the process, because the system needs to check that the callback is still wanted, that it went to the correct number, and that it didn’t hit voicemail. It also has to be timed just right, so that the available agent is not left waiting for the verification step to take place. Plus, the PSTN still doesn’t do video.
    
    BTW, American Express built an iPad app for customer service, using the WebRTC for voice and video, and no IVR was required. One interesting thing they found is that using video typically yields higher customer satisfaction than just voice calls.
    
    2. I’m working with a startup to build a patient-centered care system, using mobile apps for the primary user and their family members. Features include voice, video and document push. App users can contact a customer service agent who will put them in touch with members of the care team. The agent will use a web browser for all operations, including voice and video communications. We don’t have to worry about ubiquity of browser support for WebRTC, as we can control which browser the agent uses. Nor do we have to worry about pushing out updates to client software, as it’s all done in the browser.
    
    Reply
    1. aswath March 16, 2016
      
      I think Progressive could have avoided the loss of context simply: When it offered a call back number, it could have provided a 4 digit number that you enter when you hit the IVR. Then IVR can use the caller id number and the IVR entered number to reconstruct the context and present it to the agent.
      
      I agree contextual communication is one of the benefits of WebRTC. But it can be realized in PSTN/IVR system as well.
      
      Reply