WebRTC is an important technology that is making its way towards becoming an HTML5 standard. Mozilla and Google seem to be happy with the way things are going - but what about Microsoft?

WebRTC is a way to allow browsers to get in touch with one another using audio or video data without the help of a server. Google has been something of a pioneer in this area and submitted a suggested technology for the standard and Mozilla has gone along with it, making it all look good. Microsoft, on the other hand, just seemed to be standing on the sidelines watching what was happening.

However, Microsoft has a product that needs something like WebRTC, namely Skype. It has been working on a web-based version of Skype and this has focused the collective mind on the problems of browse-to-browser communication. It now agrees that a standard is needed, just not the one Google and Mozilla are behind.

Microsoft has submitted its own proposals for CU-RTC or Customizable, Ubiquitous Real Time Communication over the Web, to the W3C.

This has a ring of deja vu about it, because this is far from being the first time that, rather than work on the development of what is already on the table, Microsoft simply proposes an alternative. This is the sense in which Microsoft has just picked a fight as either it or Google/Mozilla will win and the loser will either have to re-implement everything or ignore the standard. In the past when Microsoft lost it simply ignored the standard and hence effectively made the standard unusable.

One of the biggest differences between the two proposals is the codec. Google and Mozilla want to use V8, which is open source. Microsoft, and also Apple, prefer the established H264 which has hardware support but is subject to royalties. Using a single codec would be simpler, but Microsoft wants support for multiple codecs in the standard.

Of course, Microsoft has a set of criticisms of Google's proposals. After outlining what the properties of a good RTC standard should be the Microsoft Interoperability blog concludes:

"While a useful start at realizing the Web RTC vision, we feel that the existing proposal falls short of meeting these requirements."

It then goes on to outline what specifically is wrong. The main point is that it isn't flexible enough to meet all deployment situations including traversing routers and working with VOIP, baby monitors and mobile phones. It is accused of being just for video communications between browsers:

"A Web RTC standard must equip developers with the ability to implement all scenarios, even those we haven’t thought of."

The second point is that it currently isn't a stateless protocol as it derives from the earlier SIP protocol;

"In particular, the negotiation model of the API relies on the SDP offer/answer model, which forces applications to parse and generate SDP in order to effect a change in browser behavior."

Of course, the new proposal is claimed to avoid all problems and fit in with the web way of doing things:

• It adds a real-time, peer-to-peer transport layer .
• It dispenses with the constraints imposed by unnecessary state machines and complex SDP and provides simple, transparent objects.
• It builds on and integrates with the existing W3C getUserMedia API, making it possible for an application to connect a microphone or a camera in one browser to the speaker or screen of another browser..

The getUserMedia API is a standard that Microsoft has been particularly involved with and so it is a natural basis for RTC.

It may well be that Microsoft's alternative has features that make is superior, but a single standard is preferable to a better non-standard. Given Microsoft's need to make Skype work in the browser, it seems likely that, should its proposal not be accepted as the standard, it will press on regardless, so splitting the development environment. Both Google and Mozilla have already put a lot of work into WebRTC and there are partial implementations in Firefox, Chrome and Opera.

This is potentially not a good development.