Delayed WebRTC standards may have unexpected side-effects

Overall, it seems that the standardisation of WebRTC is taking somewhat longer than I anticipated at the time of my strategy report’s publication in February. According to the group’s home page, at 1^st June 2013:

·         Last Call Working Draft: re-scheduled for Q1 2013, but will be further delayed (Q3 2013?)

·         Candidate Recommendation: initially scheduled for Q4 2012, but delayed probably until Q1 2014

 

I'm currently writing up the first of the quarterly updates for the report's subscribers. (What do you mean you haven't bought it yet? Sort it out....!) and one of the conundrums is that while standards are slower than I anticipated, uptake and various fields of innovation seem to be happening even faster than I'd envisaged. I'm upgrading my forecasts.

Standardisation is slow both overall in terms of finalising the IETF/W3C drafts, and specifically with certain elements within them. I'm not going to rehash the video codec debate in this post, but that's still lurking. There's also a lot of to-ing and fro-ing in the email discussion lists about the "offer/answer" approach to setting up or tearing down WebRTC sessions, especially around large multi-party conferences, which may have to endure a lot of setup latency. Add in security, enterprise considerations, needs to support various telco use-cases and techniques like network QoS, and it's unsurprising that  things are becoming more complicated. There are also a lot more stakeholders involved, many from "legacy" worlds of communications as well as the more free-wheeling web community.

But ironically, one of the side-effects of slowed standards finalisation appears to be a disproportionate effect on the telecom and “conservative enterprise” segments for WebRTC. Those groups are typically the slowest and most constrained to wait for specifications to settle down before taking action on implementation. It seems unlikely that too many operators will want to release "live" WebRTC-extended VoLTE or RCS while the standards and implementations are in a state of flux.

Conversely, web-based companies tend to be much happier with fluid pre-standard versions of APIs or capabilities. They either re-work code as new versions emerge, or rely on a host of intermediate API/cloud providers to do it for them. In the case of WebRTC, for example, there are already more than a dozen companies “wrapping” WebRTC video-chat in forms suitable for embedding into websites, providing developers with SDKs, libraries (chunks of pre-coded software downloaded with a page) and  cloud back-ends. Numerous early applications and services are using VP8 implementations for video in Chrome or Firefox - irrespective of whether we end up with a defined standard or not. 

It is the tier of enabling cloud/API providers that will bear much of the pain of standard tweaks or eventual fragmentatation – but as experts focused on the changes, they are capable of doing that with alacrity.

If anything, slowing down standards for WebRTC may only end up harming those most responsible for delaying them. For everyone else, there's already "enough to be getting on with". In my view, telcos and network equipment vendors need to try to *accelerate* the first round of WebRTC standards, as otherwise they'll get bogged down in layers of SIP-like extensions and regulatory "what-ifs". Save that stuff for 2.0. 

Separately, divisions of telcos that are not linked into the core-network/standards process should just "get on with it" and develop their own early WebRTC prototypes, sites, apps and products immediately - if necessary, disintermediating their own official "comms" platforms like IMS if they're not prepared to work on the basis of day & week cycles, rather than quarters and years.