Hurdles? What WebRTC Hurdles?

There are reasons why WebRTC isn’t waiting for anyone.

I really enjoyed reading Sean Jackson’s overview of WebRTC on Telco OTT Today. There was one bit there that I just don’t agree with – close to the end where Marc Beccue is given the stage and he lists the “hurdles” facing WebRTC. I’ll make it short – these are his hurdles:

1. Apple and Microsoft missing in action in the browser arena of WebRTC adoption
2. Technical complexity
   1. UI
   2. The CPU requirements of WebRTC on mobile
   3. Lack of signaling specification and SIP interoperability
3. Poor user experience – due to the best effort nature of VoIP

Never trust a market analyst.

Let’s talk about these hurdles for a minute and how they are irrelevant.

Apple and Microsoft missing

• Google and Firefox comprise 50% of the browser market – give or take a few percent. This is enough for a lot of vendors
• On Microsoft’s IE, there’s Chrome Frame as an extension that can give WebRTC access
• On mobile, there are a lot of use cases that don’t require a browser but rather rely on an app, and there, WebRTC can be ported and used today. In fact – there are several companies already doing that

Even if they end up delaying their introduction of WebRTC browsers, its adoption and use is guaranteed.

UI

How is the user interface any different between whatever it is you do with WebRTC to Flash, a VoIP app or any other app???

Different video calling products today have a similar product: they need to deal with different camera resolutions, screen sizes and screen resolutions. WebRTC doesn’t add or reduce from that fact.

CPU requirements

So, video calling requires a lot of CPU. This isn’t a hurdle for WebRTC – it is a hurdle for Skype on a mobile device – for Tango – for ooVoo – and for a handful of other such applications that have nothing to do with WebRTC.

And guess what? People still use them. The main benefit of WebRTC in this regard, is that now, there’s more of a chance that handsets will get them integrated from the chipset level and up to the application layer of the browser. Things can only get better because of WebRTC in this domain.

Lack of signaling spec

Yada yada yada signaling yada yada yada SIP yada yada yada SDP yada yada yada

Noise. Pure noise. Pick up your signaling of choice and use it. Want SIP? There’s SIP available. Like XMPP? Likewise. Prefer your existing signaling? Go for it.

And that issue of interoperability – it is relevant for only those that need it, and there are at least 3 different “world first” gateway press releases out there of connecting WebRTC to X.

Poor user experience

So, WebRTC is ‘best effort’. It isn’t as good as PSTN’s circuit switching. That’s VoIP for you. This is how Skype works. And Lync. And a Cisco Telepresence system. Oh… and it is how the carrier’s VoLTE solution works.

We are shifting from a circuit switching network mindset to a packet switching one. Best effort is what we get, and it is what we need to live with. This is why WebRTC opted for Opus as a voice codec in the first place (well, that and high definition).

If anything, WebRTC reduces the effects of this problem by shifting the responsibility of it from each and every vendor and developer to a handful of browser vendors.

The real hurdle

The hurdles Marc mentions are mostly generic ones related to VoIP and video conferencing. As such, they have no real weight on WebRTC. The real hurdle of WebRTC? The need for better examples and howto documents for the infrastructure size of the story.

So yes. There are hurdles ahead of WebRTC. And work to be done. And ups and downs. And patent litigation.

To me this just makes it real instead of a hobby protocol.