What is this site?

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.

CU-RTC-Web Roaming

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.

With this latest version, we are demonstrating another important interoperability scenario - roaming between two different connections (e.g. Wi-Fi and 3G, or Wi-Fi and Ethernet) - with negligible impact on the user experience. The simple, flexible, expressive APIs underlying the CU-RTC-Web architecture allowed us to implement this important scenario just by building the appropriate JavaScript code and without introducing any changes in the spec, because CU-RTC-Web is a lower level API than the current proposed WebRTC API draft. 

By comparison, the current high level proposed WebRTC API draft would not allow JavaScript developers to implement this scenario: the current draft would need to see modifications done under the hood at the Platform level by the developers developing the browser capability itself.

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:

  • Clarify the CU-RTC-Web proposal with interoperable working code so others can understand exactly how the API could be used to solve real-world use cases.
  • Encourage others to show working example code that shows exactly how their proposals could be used by developers to solve use cases in an interoperable way.
  • Seek developer feedback on how the CU-RTC-Web addresses interoperability challenges in Real Time Communications.
  • Provide a source of ideas for how to resolve open issues with the current draft API as the CU-RTC-Web proposal is cleaner and simpler.