The What’s Next for WebRTC Can Wait Until We Deal With What’s Now

By Tsahi Levent-Levi

October 22, 2015  

Why reminisce in the future when we’ve got so much to do in the here and now.

This week Chad wrote a post titled What’s Next for WebRTC? It is a good post, so don’t get this one as a rant or a critique about Chad. It is just the moment I saw the title and some of the words on the accompanying visual (AR, VR, drones, Industrial, Computer Vision, 3D, Connected Cars) – I immediately knew there’s something that bugs me.

It wasn’t about the fact that WebRTC isn’t used for any of these things. It was due to two reasons:

  1. We’re still not scratching the surface of WebRTC yet, so what’s the rush with what’s next?
  2. I hate it when people stick a technology on anything remotely/marginally related. This is the case for the soup of words I saw in the visual…

The second one, of buzzword abuse, I can only say this: WebRTC may play a role in each and everyone of these buzzwords, but its place in these market will be minuscule compared to the market itself. For many use cases in these markets, it won’t be needed at all.

For the first one, I have decided to write this.

There are many challenges for those who wish to use WebRTC today. This is something I tried to address in the last Kranky Geek event – WebRTC is both easy and hard – depending on your pedigree.

WebRTC complexity?

VoIP developers will see it as the easiest way to implement VoIP. Web developers will find it hard – it is the hardest thing that you can add to a browser these days, with many moving parts.

Here’s the whole session if you are interested:

Here’s what I think we should strive for with WebRTC and even ask those who work to make it available for us as a technology:

#1 – Become TCP

TCP works. We expect it to work. There are no interoperability issues with TCP. And if there are, they are limited to a minuscule number of people who need to deal with it. WebRTC isn’t like it today.

WebRTC requires a lot of care and attention. This fresh interview with Dan about the WebRTC standard shows that. You’ll find there words about versioning, deprecation, spec changes, etc. – and the problem is they affect us all.

This brings us to this minor nagging issue – if you want to use and practice WebRTC, you need to be on top of your game and have your hand on the WebRTC pulse at all times – it isn’t going to be a one-off project where you invest in developing a web app or an app and then monetize and bask in the sun for years.

The other alternative is to use a WebRTC API vendor, who needs to take care of all that on his own. This can’t be easily achieved by those who need an on premise deployment or more control over the data. This alternative also speaks louder to developers than it does to IT managers in enterprises, leaving out part of the industry of potential adopters of WebRTC.

The faster WebRTC becomes like TCP the better.

#2 – More success stories of a variety of simple use cases

There are a lot of areas where I see vendors using WebRTC. Healthcare, learning, marketplaces, contact centers, etc.

In many cases, these are startups trying to create a new market or change how the market works today. While great, it isn’t enough. What we really need is stories of enterprises who took the plunge – like the story told by AMEX last year. We also need to see these startups grow and become profitable companies – or larger vendors who acquire technology (I am talking to you Slack, Atlassian and Blackboard) use them in their products.

These stories that I am interested in? They should be able the business side of things – how using WebRTC transformed the business, improved it, got adopted by the end customers.

Where are we?

With all the impressive numbers of WebRTC flying around, we still are in the early adopters phase.

We are also still struggling with the basics.

There are many great areas to explore with WebRTC – the large scale streaming space is extremely interesting to me. So is the potential of where WebRTC fits in IOT – which is even further out than the large scale streaming one. I love to be a part of these projects and those that seek them are at the forefront of this technology.

We’re not there yet.

But we will be.

There’s no stopping this train any time soon.


You may also like

Leave a Reply

Your email address will not be published. Required fields are marked

  1. Staying on top of it… Chrome 46 just changed the protocol field in the m-line from RTP/SAVPF to UDP/TLS/RTP/SAVPF. I’ve heard of a number of people whose stuff was broken, mostly really old library versions. Chrome had the backward compatibility support for this since mid-2014 and the change in the send-part was announced months ago.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}