Microsoft goes its own way with Web audio/video spec, despite W3C rebuff | Ars Technica

Microsoft has published a working prototype of CU-RTC-Web, its proposed specification for enabling browser-based, plugin-free, real-time audio and video communication.

CU-RTC-Web isn't the only proposal for such a specification. In fact, it's not even the main one. The World Wide Web Consortium (W3C), the group that formalizes the development and specification of Web-related standards, has its own group working on a plugin-free, real-time audio and video communication specification called WebRTC. Preliminary—and somewhat rudimentary—support for WebRTC is found in current versions of Chrome and Firefox.

This support certainly isn't finished yet, and interoperability between the browsers remains troublesome—many of the online WebRTC demos are built for Chrome alone and won't work with Firefox at all—but in theory they're on track to support the same specification in a manner that will eventually be compatible.

Redmond first announced CU-RTC-Web in August. Along with the specification itself, the company produced a rationale; a list of reasons why it felt that WebRTC was a bad fit for the problem at hand, and why CU-RTC-Web was a superior solution. Perhaps the most specific complaint was that WebRTC was quite deeply linked to a specification called SDP, an open industry standard used extensively for VoIP and video conferencing systems in conjunction with SIP, with Microsoft arguing that this is over-complicated and hinders interoperability with non-SDP systems. SDP is used to negotiate the parameters of the connection; things like the bandwidth, the IP addresses and port numbers to use, and so on.

It just happens that Microsoft has non-SDP products of its own—Skype (which remains stubbornly proprietary and undocumented) and Lync (which can bridge with SIP systems, and hence understands SDP, but offers alternative APIs too).

Although W3C's WebRTC working group acknowledged that the current WebRTC spec has parts that are as-yet incomplete, a vote carried out in September to choose between the two paths was heavily in favor of WebRTC. It won with 22 votes to just 4 for Microsoft's proposal.

So what's Microsoft playing at, persevering with its own spec in spite of its rejection by the WebRTC group?

The company's argument is twofold. First, WebRTC simply isn't complete yet, and Microsoft believes that working on its proposal can shed light on how to solve certain problems such as handling changes in network bandwidth or keeping cellular and Wi-Fi connections open in parallel to allow easy failover from one to the other. Even if Redmond's spec isn't adopted wholesale, portions of it may still be useful.

Second, the company believes that WebRTC may not be as close to real standardization as its proponents might argue. The problem is SDP. SDP wasn't originally designed for browser-to-browser communications, and some of the things that WebRTC uses it for go above and beyond the specification. For example, WebRTC wants to be able to include multiple streams multiplexed over a single connection. Doing that will require extensions to SDP. Different SDP implementations also struggle to achieve compatibility; the SDP specification permits multiple conflicting interpretations, with Microsoft and others claiming that the implementations in Chrome and Firefox are incompatible. There are similar difficulties in getting Chrome to talk to existing SIP systems such as Asterisk. Both ends are using SDP—they're just not using the same interpretation of SDP.

The SDP standard isn't governed by W3C. IETF's MMUSIC ("Multiparty Multimedia Session Control") Working Group is in charge of SDP. That group will have to incorporate the new features that the WebRTC group needs, and it will have to do so in a manner that remains compatible with existing deployments of SIP and related protocols.

Until these updates and extensions to SDP are standardized, WebRTC cannot be finalized. That standardization could be quick, if MMUSIC fast-tracks the modifications, but that's not guaranteed. There are compatibility constraints, and these can be hairy. The MMUSIC group may be unwilling to risk breaking extant SIP deployments just to add support for WebRTC.

Underlying all of this is a somewhat different attitude regarding what WebRTC is for. Many in the group, including its chairperson, maintain that browser-to-browser communication is the most important use case. Microsoft, however, wants a more general set of APIs, suitable not just for browser-to-browser communication, but browser-to-legacy-software, browser-to-switchboard, and browser-to-anything else that might make sense.

It's already clear that developers experimenting with Chrome's WebRTC support want to do more than merely communicate with other browsers (such as the previously mentioned attempts to connect to Asterisk), so Microsoft's viewpoint appears to have some resonance with actual developers.

The CU-RTC-Web proposal is lower level, and a SIP system using SDP could be built on top of it if desired; it just doesn't require SDP.

Microsoft's prototype implementation works in Internet Explorer 10 and the latest version of Chrome. In both browsers, it works as a plugin, providing JavaScript programs a version of the CU-RTC-Web API. With this prototype, the company is demonstrating that its proposals do work in practice and could provide a solution to the problems with SDP.

Even backers of the current WebRTC specification acknowledge that the SDP problems have so far proven intractable. The WebRTC spec hinges on getting SDP fit for purpose. If a quick resolution to the difficulties can be found then WebRTC will be here to stay. But if it can't, the working group might want to revisit Microsoft's SDP-less proposal. The best solution to the SDP problems could be to stop using SDP entirely.

Listing image by Frédéric Bisson