Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Tuesday, January 15, 2013

WebRTC - not just about browsers

At the moment, most observers' commentary about WebRTC involves asking about "browser support", which is understandable given that it comes under the HTML5 and W3C banner.

**NEW Feb 2013 - Disruptive Analysis WebRTC report - details here**

So we see support for WebRTC in the current "public" desktop versions of Google Chrome and - just this week - Firefox. The implementations could still be referred to as "early", but they're out there in real users' hands, not just developers using beta versions. (You'll also sometimes see references to WebRTC being "behind a flag" which means that it's available as an advanced feature if you fiddle around with settings).

Unsurprisingly, conversation then tends to turn to when WebRTC might be supported in Microsoft IE, Safari and so on, for PCs and Macs. Mobile browsers then tend to get discussed next, with mutterings about users' reticence to download and install second browsers on phones and tablets - generally, most "normal" users stick to whatever the phone is equipped with "out of the box" today. So then the predictions start to ponder when the Android browser might support WebRTC, people bemoan Apple's apparent slow pace of adoption ("hmm, they don't want it to compete with FaceTime"), or Microsoft's perceived slowness.

Actually, the picture is more complex than that, especially on mobile, but also on the desktop.

Looking at smartphones, there are actually 4 main possible paths for getting WebRTC support onto mobile devices:

  • Support by the default browser that the phone ships with
  • Support by a downloadable secondary/replacement browser (complicated on iOS because Apple doesn't allow a separate web-rendering "engine" - they need to be built around Webkit). Ericsson's Bowser is already out, and expect Chrome/Opera/Firefox etc in future as well.
  • Support in the OS. This hasn't happened yet, but many expect to see native support for WebRTC APIs in the platform itself, allowing apps to exploit the capabilities, not just web-pages. I'm having lots of interesting debates about which OS vendors might do this first.
  • BYOWebRTC approaches, where individual apps actually integrate WebRTC elements - media engine & all - typically provided by using an SDK from one of a growing number of providers offering APIs, cloud "enablers" and other building-blocks
All this is further clouded by upcoming web-based OS's like Firefox OS, BB10 and Tizen, where it's not entirely clear where the boundary is between OS and browser anyway. There's also no guarantee that future phones will always ship with the platform's "normal browser" - so for example Samsung could ship Galaxies with a tweaked version of the basic Android browser, use Chrome-for-Android instead, or even develop its own from the ground up. (There's also a small matter of supporting all of the WebRTC APIs, or just some of them).

Then there are some other wildcards - we may see WebRTC acceleration performed in silicon at some point (eg video codecs and media processing). Also - and I think I'm the first person to mention this - there's no reason that WebRTC needs to be confined to the browser or aftermarket apps on the phone. Maybe we'll see it crop up elsewhere, such as in email clients, enabling direct interaction with HTML5 emails inside the message. Standby for two-way video spam....

A similar is story is also true on the desktop, but I expect that browsers will "get there first" for the most part. So we could see downloadable applications (Enterprise softphones? Games? Skype? Outlook?) that incorporate bits of WebRTC rather than, or in addition to, their normal media engines. This would allow much tighter control of the experience than relying on browser tabs and windows, and probably make it easier to integrate comms with enterprise apps, security and assorted other features.

Overall, anybody asserting that WebRTC will only take off "when all the browsers support it" is missing half the story, especially on mobile. The reality is considerably messier - and should mean things happen a bit faster than they otherwise might.

**NEW Feb 2013 - Disruptive Analysis WebRTC report - details here**


Tsahi said...

Until there will be a native browser with support of WebRTC on a major mobile handset operating system, the way we will be "consuming" WebRTC services will be through the app model: http://bloggeek.me/webrtc-mobile/

Users can't be expected to download specific browsers to gain access to websites.

Dean Bubley said...

Probably true - but then enough people download replacement browsers on PCs (especially Chrome & Firefox) that the behaviour might leak through to mobile devices too.

Virtually everyone I know with a Mac uses Chrome rather than Safari, so it's possible that will translate to tablets & phones.

That could also skew use-cases for early adopters indirectly.

Ramsundar Kandasamy said...

1.Once we have the support from the platform, then any app (even webview based) can make use of the webrtc apis, which otherwise be provided only by the browsers.

2."...there's no reason that WebRTC needs to be confined to the browser or aftermarket apps on the phone."
There are already some webrtc protoype software that i know that that are neither browser based or mobile app based. Eg. you connect to a server using the peerconnection api and the server does something on the media before it is forwarded to the original 'B' party.

Ramsundar Kandasamy said...

Another use case is a partial implementation of the webrtc APIs. Eg. It would be great to have the DataChannel API in place, before websockets are in place on different platforms/browsers.

Kavan Seggie said...
This comment has been removed by the author.
Kavan Seggie said...

I think native apps will almost always trump web apps. They offer better usability. I think WebRTC in apps is more likely to take-off, at least in the short term.

We are getting requests for WebRTC PhoneGap bindings so this seems to back this point up.