New CU-RTC-Web HTML5Labs Prototype from MS Open Tech Demonstrates Roaming between Cellular and Wi-Fi Connections

  • Article

Demonstrating a faster mobility scenario that would be more difficult with the current WebRTC draft

Adalberto Foresti
Principal Program Manager, Microsoft Open Technologies, Inc.

Since we submitted the initial CU-RTC-Web proposal to the W3C WebRTC Working Group in August 2012 with our proposed original contribution, vibrant discussions over the proposed RTCWeb protocol draft and WebRTC APIs specifications have continued both online and at face to face W3C and IETF Working Group meetings. The amount of energy in the industry around this subject is remarkable, though the road to converge on a quality, implementable spec that properly addresses real-world use cases remains long.

Last month, our prototype of CU-RTC-Web demonstrated a real world interoperability scenario – voice chatting between Chrome on a Mac and IE10 on Windows via the API.

Today, Microsoft Open Technologies, Inc., (MS Open Tech) is now publishing an updated prototype implementation of CU-RTC-Web on HTML5Labs that demonstrates another important 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 modifying the browser capability itself. There is a proposal for addressing mobility cases in the IETF, but standardization of these mechanisms and subsequent implementation in the browser takes time.

This example also illustrates that we should not assume 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 recently been 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.

The prototype can be downloaded from HTML5Labs. We look forward to receiving your feedback: please comment on this post or send us a message once you have played with the API, and stay tuned for even more to come.

We are proud to be part of the process and will continue to collaborate with the working group to close the gaps in the specification in the coming months. We remain persuaded that the general principles that governed CU-RTC-Web are valid and that a lower level API such as CU-RTC-Web is preferable to the higher level API within the current proposed WebRTC API draft.  This would result in the most agile and robust standard, one that will empower web developers to create innovative experiences for years and decades to come.