About six months ago, Microsoft released an alternative proposal to the W3C WebRTC 1.0 Working Draft, dubbed CU-RTC-Web. Like all W3C groups, the WebRTC Working Group enlists membership from a majority of the industry, including names like Nokia, Cisco, Google, and Mozilla. The most important question raised by the Microsoft proposal is how the Working Group would react to criticism of its draft proposal, and whether Microsoft would accept the published APIs of the Working Group, even if CU-RTC-Web is not adopted. So what exactly does this mean for the development community?
The Microsoft draft outlines a low-level API that allows developers more direct access to the underlying network and media delivery components. It exposes objects representing network sockets and gives explicit application control over the media transport. In contrast, the WebRTC API abstracts these details with a text-based interface that passes encoded strings between the two participants in the call. With the WebRTC draft, developers are responsible for passing the strings between communicating browsers, but not explicitly configuring media transport for a video chat.
Shortly after Microsoft announced CU-RTC-Web, the W3C Working Group voted on whether to incorporate the alternative ideas from the Microsoft proposal. The Working Group decided to continue using SDP to configure media transport. Microsoft is continuing forward with CU-RTC-Web, and recently released a demo using the proposed API.
As far as web developers are concerned, this is both good news and bad. While it appears that face-to-face communication will be supported in all browsers, they may not work together seamlessly. For OpenTok users, there’s no need to worry. We will continue to offer a consistent API that bridges the technical gaps left behind by the standards development process. OpenTok on WebRTC will work across all browsers and will tackle interoperability issues of today, and tomorrow.