I attended the WebRTC (Web Real-Time Communication) conference in San Jose last month. This is the second consecutive year I've gone to the show. Discussions at last year's conference typically centered on what video codec to use and if anyone would ever pay for the technology. My take from this year's conference is that, though some of the technical issues have been resolved, WebRTC still faces some obstacles before enterprises can look at it as a serious solution.
The IETF and W3C standards bodies that govern the project agreed to support both VP8 and H.264 video codecs. This represents a big leap forward in terms of technical development. It is a good thing for the smartphone/tablet market, because many of the chips these manufacturers use already have H.264 hardware acceleration, which improves performance and helps with battery drainage. Google continues to improve the video codecs, showing VP9 demos that are already being productized.
Despite these technical achievements, there are a few barriers that need to be addressed before WebRTC can go mainstream.
First, there are four major browsers in the world today, all of which need to support the standard fully and ensure interoperability: Microsoft's Internet Explorer (IE), Google Chrome, Mozilla Firefox, and Apple's Safari. Both Chrome and Firefox are active in WebRTC integration. Up to a few days ago, Microsoft was standing on the sidelines, which was a major issue for the people pushing the solution, because IE is still the top browser for desktop machines.
Microsoft did announce support for the ORTC API, which is currently in a concept stage within the standard; that means it will be a year or more before there is anything real. It's a step in the right direction, and, from what I heard, the ORTC API will improve the interface that controls the media streams -- something that is needed for more adaptable solutions. At this point, Apple has yet to announce a strategy for WebRTC publicly.
Second, there needs to be a single company that will respond to the issues IT managers experience with the technology. The developers for the big four browsers are not typically responsive when network issues are impacting their applications. Their dealer networks can pick this ball up, but they have only so much power if there is a real problem with the code.
There is also the issue with the client versus the server: WebRTC requires call routing and network traversal technology to enable the clients. These are currently being developed by other companies, so now, if a problem occurs, there are at least two phone calls to make. Though I saw some very cool demos of solutions, I am not confident of how robust they are at this time.
Third, the browser model offers some serious UI flexibility for application developers. An army of web programmers, now or in the future, will have their options for how to make video communications work for web pages and vertical markets.
But what problem does this solve for the enterprise deployments? It's not clear to me that the barrier has been access or UI design. Skype has been free for many years, and it works pretty well for many of the call scenarios, yet it's still lightly adopted for enterprise use. Will having the same feature set in a browser change the equation? Does the smartphone/tablet model move things back to an application model?
For WebRTC to break the barriers in the enterprise market, we will need a few service providers (or companies that look like them) to step up and build a bundled offering of all the components, including a support model. This solution would include all the peripherals for video and audio, including high-quality UC audio collaboration equipment, as well as the server components and management applications to support it all.
Until a holistic solution is provided, progress will continue to be made in the consumer market but will lag in the enterprise market.