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.
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:
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.