I'm currently updating the WebRTC forecast model used in the Disruptive Analysis research strategy report & update subscription service. A core part of it examines the likely penetration of WebRTC capabilities into different classes of device, via browsers or other paths.
Most in the industry will know that Chrome browsers already support WebRTC switched-on by default (albeit in its current pre-standard form), with Firefox support close behind in its Beta version. There is much speculation about if/when Apple and Microsoft might follow. I've got my own views on that, with my assumptions stated and baked into my forecasts.
But there is a critical difference here - there is a very large legacy installed base of IE browsers, and to some extent Safari as well - that doesn't auto-update to the latest version. IE9, 8, 7 and even 6 are still lurking around, especially in certain countries either with lots of old PCs, or for corporate users whose CIOs lock down application updates and installs.
How is WebRTC going to be extended to those last hold-outs, even if IE11/12 or future versions of Safari support it?
One option commonly discussed is Google's Chrome Frame plug-in for IE. However, it is unclear whether anybody who still uses an old version of IE is going to readily want - or be allowed - to install a new plug-in. The whole point of WebRTC is to avoid plug-ins, especially for occasional audio/video tasks such as conferencing.
(Sidenote: I have a growing hatred of all the various web conference tools that vendors briefings or clients/contacts force me to use - no, I don't want to have to sign in 15 minutes in advance to make sure it all works and I've downloaded whatever chunks of software are supposed to help. Increasingly I turn down such requests, asking instead for a PSTN dial-in and emailing me the PDF presentation - or, alternatively, force *them* to use my choice: Skype).
So, I'm doubtful that Chrome Frame is going to do much to extend the reach of WebRTC to many of the old-browser community. Maybe Google can cunningly force its use by pushing it as a way to enable/enhance GMail or Hangouts, but it's not obvious that's the case.
I had an interesting thought yesterday though - most of those old browsers will already have Flash and Java plug-ins (as well as maybe Silverlight and others). Maybe the "vector" for WebRTC support on "old IE" will turn out to be Adobe or Sun (ie now Oracle), if they include it within the next updates of users' current plug-ins? Obviously Adobe still has its own competing RTMP & RTFMP protocols, but it must surely by now see the writing on the wall, much as it has with Flash vs. H.264? Could it gain relevance by being a lead provider of WebRTC APIs? Provide a combination of the two with RTFMP as a fallback or way to manage certain scenarios? Maybe even get subsidised by Google to help extend WebRTC's reach more quickly....
The Oracle/Sun/Java pitch is perhaps easier - it wouldn't surprise me at all, and there are some obvious synergies with the acquisition of Acme Packet.
(Note - I have no inside knowledge of either of these; both are total speculation on my part. I'm actually embarrassed I didn't ask Oracle or Acme about it - or even just suggest it - when I met them recently).
One question I haven't thought through though - what would this mean for PCs which end up with two or more WebRTC implementations? Native browser capability, plus plug-in, plus maybe the sort of web-app Javascript/API approach we see from AddLive or Plivo and others? Will there just be a "default WebRTC engine" or will it be managed in another way? It strikes me that we'll definitely see smartphones and tablets with 2+ implementations of WebRTC, so this issue will need to be addressed anyway.
Most in the industry will know that Chrome browsers already support WebRTC switched-on by default (albeit in its current pre-standard form), with Firefox support close behind in its Beta version. There is much speculation about if/when Apple and Microsoft might follow. I've got my own views on that, with my assumptions stated and baked into my forecasts.
But there is a critical difference here - there is a very large legacy installed base of IE browsers, and to some extent Safari as well - that doesn't auto-update to the latest version. IE9, 8, 7 and even 6 are still lurking around, especially in certain countries either with lots of old PCs, or for corporate users whose CIOs lock down application updates and installs.
How is WebRTC going to be extended to those last hold-outs, even if IE11/12 or future versions of Safari support it?
One option commonly discussed is Google's Chrome Frame plug-in for IE. However, it is unclear whether anybody who still uses an old version of IE is going to readily want - or be allowed - to install a new plug-in. The whole point of WebRTC is to avoid plug-ins, especially for occasional audio/video tasks such as conferencing.
(Sidenote: I have a growing hatred of all the various web conference tools that vendors briefings or clients/contacts force me to use - no, I don't want to have to sign in 15 minutes in advance to make sure it all works and I've downloaded whatever chunks of software are supposed to help. Increasingly I turn down such requests, asking instead for a PSTN dial-in and emailing me the PDF presentation - or, alternatively, force *them* to use my choice: Skype).
So, I'm doubtful that Chrome Frame is going to do much to extend the reach of WebRTC to many of the old-browser community. Maybe Google can cunningly force its use by pushing it as a way to enable/enhance GMail or Hangouts, but it's not obvious that's the case.
I had an interesting thought yesterday though - most of those old browsers will already have Flash and Java plug-ins (as well as maybe Silverlight and others). Maybe the "vector" for WebRTC support on "old IE" will turn out to be Adobe or Sun (ie now Oracle), if they include it within the next updates of users' current plug-ins? Obviously Adobe still has its own competing RTMP & RTFMP protocols, but it must surely by now see the writing on the wall, much as it has with Flash vs. H.264? Could it gain relevance by being a lead provider of WebRTC APIs? Provide a combination of the two with RTFMP as a fallback or way to manage certain scenarios? Maybe even get subsidised by Google to help extend WebRTC's reach more quickly....
The Oracle/Sun/Java pitch is perhaps easier - it wouldn't surprise me at all, and there are some obvious synergies with the acquisition of Acme Packet.
(Note - I have no inside knowledge of either of these; both are total speculation on my part. I'm actually embarrassed I didn't ask Oracle or Acme about it - or even just suggest it - when I met them recently).
One question I haven't thought through though - what would this mean for PCs which end up with two or more WebRTC implementations? Native browser capability, plus plug-in, plus maybe the sort of web-app Javascript/API approach we see from AddLive or Plivo and others? Will there just be a "default WebRTC engine" or will it be managed in another way? It strikes me that we'll definitely see smartphones and tablets with 2+ implementations of WebRTC, so this issue will need to be addressed anyway.
Dean,
ReplyDeleteThis is a great idea.
As to the actual mechanics of it - these plugins can use slightly different names for their APIs, making it relatively easy for a wrapper like webRTC.io (https://github.com/webRTC/webRTC.io) to do the "heavy lifting" of deciding which version you have.