HTML5Labs is where Microsoft prototypes early and unstable specifications from web standards bodies such as W3C. Sharing these prototypes helps us have informed discussions with developer communities, and enables us to provide better feedback on draft specifications based on this implementation experience. To find out more about HTML5Labs, read the blog by Dean Hachamovitch, Corporate Vice President for Internet Explorer, and the blog by Jean Paoli, President, Microsoft Open Technologies, Inc.
We are updating our previous prototype where we demonstrated a real world interoperability scenario - voice chatting between Chrome on a Mac and IE10 on Windows via the API.
This example also illustrates that we should not assume that everything that will ever be done with WebRTC is already known at the time the standard is developed. It is tempting to develop an opaque, high level API that is optimized for some well-understood scenarios, but that requires development of new, probably non-interoperable extensions to cover new scenarios… or creating yet another standard to enable such applications. We believe that web developers would prefer to be empowered by a lower level, general API that truly enables evolving, interoperable scenarios from day one. Our earlier CU-RTC-Web blog described critical requirements that a successful, widely adoptable Web RTC browser API will need to meet, particularly in the area of network transport. We mentioned how the RealtimeTransport class connects a browser with a peer, providing a secured, low-latency path across the network.
Rather than using an opaque and indecipherable blob of SDP: Session Description Protocol (RFC 4566) text, CU-RTC-Web allows applications to choose how media is described to suit application needs. The relationship between streams of media and the network layer they traverse is not some arcane combination of SDP m= sections and a=mumble lines. Applications build a real-time transport and attach media to that transport.
If you want to learn more about the challenges that SDP brings, some very insightful comments have been recently shared by Robin Raymond of Open Peer on the RTCWEB IETF mailing list. Go here to see Robin's well-crafted Blog post on the issues - SDP the WebRTC Boat Anchor. As a community, it is important we continue to share these views as inaction will constitute a self-defeating choice, for which the industry would pay a high price for years to come.
As with our previous release, we hope that publishing this latest working prototype in HTML5Labs provides guidance in the following areas: