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 Jean Paoli, President, Microsoft Open Technologies, Inc.

CU-RTC-Web-Video

THIS PROTOYPE IS OBSOLETE AND UNSUPPORTED - Please check here instead.

This new CU-RTC-Web prototype continues our exploration of alternatives to the SDP Offer/Answer approach.  The CU-RTC-Web approach is based on two basic principles: that JavaScript APIs for real time communications should not be based on passing under-specified SDP blobs and should not require implementation of the SDP Offer/Answer state machine.  These principles, first articulated in the original CU-RTC-Web proposal have continued as basic tenets within our prototyping efforts, which have demonstrated the practicality of the approach with running code. 

Previous prototypes of CU-RTC-Web included demonstrations of cross-platform interoperability (voice interop between Chrome on a Mac and IE10 on Windows) and roaming between cellular and Wi-Fi connections. Because CU-RTC-Web is a contribution to the ongoing standardization process, it does not represent a planned feature of any Microsoft product, and the prototypes should not be used for the development of commercial products.

This prototype demonstrates how to support H.264/AVC video without SDP, by building the appropriate JavaScript code and without introducing any changes in the specification.

The installer on the download page supports both IE10 and Chrome on Windows 7/8. It also downloads the source code necessary to set up the server that mediates the connection between the browsers. Anyone who is interested is welcome to connect to our test server (Disclaimer: the server's bandwidth is limited, so it may not provide an optimal experience if too many users attempt to connect).

Please check the documentation page for details on how to run the prototype once the plugin is installed. You are also encouraged to inspect the JavaScript running in the test pages to appreciate how straightforward it is to implement common functionality for a Real Time Communication scenario such as putting a call on "hold":

To pause the call, the party initiating the Hold calls the "pause" method on both remote and local real-time media streams (if a call has both audio and video then two separate pause invocations are needed). Then it notifies its peer via signaling.

                 

function onHoldButtonClicked () {

localRealtimeMediaStream.pause();

remoteRealtimeMediaStream.pause();

signalling.sendOnHoldMessage();

}

 

When the peer receives the notification, it pauses its streams as well:

 

function OnHoldMessageReceived() {

localRealtimeMediaStream.pause();

remoteRealtimeMediaStream.pause();

}

 

To resume the call, both peers simply need to call "play" method again on their local and remote streams following a similar pattern. Note that all of this does not require any special plumbing, and can be built directly through the APIs documented in the spec.

Achieving the same via SDP would require the cumbersome exchange of multiple O/A messages and would likely result in code that is hard to read and maintain, and most importantly, presents very serious challenges for interoperability between different implementations.

For that reason, we believe that the open web should adopt an API based on the principles we supported early on in our participation to the WebRTC standardization efforts. We encourage all developers to partake by joining the discussion in the W3C and IETF working groups.