Re: Microsoft API Proposal

Thank you for offering this proposal!

I am looking forward to reviewing it with the working group once the 
document has been officially entered (in the link you gave, the links to 
"this submission" at W3C still give 404s).

                Harald, wearing his WG chair hat

On 08/06/2012 09:40 PM, Martin Thomson wrote:
>
> Today, we are pleased to announce Microsoft’s contribution of 
> the CU-RTC-Web proposal to the W3C WebRTC working group.
>
> Thanks in no small part to the exponential improvements in broadband 
> infrastructure over the last few years, it is now possible to leverage 
> the digital backbone of the Internet to create experiences for which 
> dedicated media and networks were necessary until not too long ago.
>
> Inexpensive, real time video conferencing is one such experience.
>
> The Internet Engineering Task Force and the World Wide Web Consortium 
> created complementary working groups to bring these experiences to the 
> most familiar and widespread application used to access the Internet: 
> the web browser. The goal of this initiative is to add a new level of 
> interactivity for web users with real-time communications (Web RTC) in 
> the browser.
>
> While the overarching goal is simple to describe, there are several 
> critical requirements that a successful, widely adoptable Web RTC 
> browser API will need to meet:
>
> * Honoring key web tenets – The Web favors stateless interactions 
> which do not saddle either party of a data exchange with the 
> responsibility to remember what the other did or expects. Doing 
> otherwise is a recipe for extreme brittleness in implementations; it 
> also raises considerably the development cost which reduces the reach 
> of the standard itself.
>
> * Customizable response to changing network quality – Real time media 
> applications have to run on networks with a wide range of capabilities 
> varying in terms of bandwidth, latency, and packet loss.  Likewise 
> these characteristics can change while an application is running. 
> Developers should be able to control how the user experience adapts to 
> fluctuations in communication quality.  For example, when 
> communication quality degrades, the developer may prefer to favor the 
> video channel, favor the audio channel, or suspend the app until 
> acceptable quality is restored.  An effective protocol and API should 
> provide developers with the tools to tailor the application response 
> to the exact needs of the moment.
>
> * Ubiquitous deployability on existing network infrastructure – 
> Interoperability is critical if WebRTC users are to communicate with 
> the rest of the world with users on different browsers, VoIP phones, 
> and mobile phones, from behind firewalls and across routers and 
> equipment that is unlikely to be upgraded to the current state of the 
> art anytime soon.
>
> * Flexibility in its support of popular media formats and codecs as 
> well as openness to future innovation – A successful standard cannot 
> be tied to individual codecs, data formats or scenarios. They may soon 
> be supplanted by newer versions that would make such a tightly coupled 
> standard obsolete just as quickly. The right approach is instead to 
> support multiple media formats and to bring the bulk of the logic to 
> the application layer, enabling developers to innovate.
>
> While a useful start at realizing the Web RTC vision, we feel that 
> the existing proposal falls short of meeting these requirements. In 
> particular:
>
> * No Ubiquitous deployability: it shows no signs of offering real 
> world interoperability with existing VoIP phones, and mobile phones, 
> from behind firewalls and across routers and instead focuses on video 
> communication between web browsers under ideal conditions. It does not 
> allow an application to control how media is transmitted on the 
> network. On the other hand, implementing innovative, real-world 
> applications like security consoles, audio streaming services or baby 
> monitoring through this API would be unwieldy, assuming it could be 
> made to work at all. A Web RTC standard must equip developers with the 
> ability to implement all scenarios, even those we haven’t thought of.
>
> * No fit with key web tenets: it is inherently not stateless, as it 
> takes a significant dependency on the legacy of SIP technology, which 
> is a suboptimal choice for use in Web APIs. In particular, the 
> negotiation model of the API relies on the SDP offer/answer model, 
> which forces applications to parse and generate SDP in order to effect 
> a change in browser behavior. An application is forced to only perform 
> certain changes when the browser is in specific states, which further 
> constrains options and increases complexity. Furthermore, the set of 
> permitted transformations to SDP are constrained in non-obvious and 
> undiscoverable ways, forcing applications to resort to trial-and-error 
> and/or browser-specific code. All of this added complexity is an 
> unnecessary burden on applications with little or no benefit in return.
>
> The Microsoft Proposal for Customizable, Ubiquitous Real Time 
> Communication over the WebFor these reasons, Microsoft has contributed 
> the CU-RTC-Web proposal that we believe does address the four key 
> requirements above.
>
> * This proposal adds a real-time, peer-to-peer transport layer that 
> empowers web developers by having greater flexibility and 
> transparency, putting developers directly in control over the 
> experience they provide to their users.
>
> * It dispenses with the constraints imposed by unnecessary state 
> machines and complex SDP and provides simple, transparent objects.
>
> * It elegantly builds on and integrates with the existing 
> W3C getUserMedia API, making it possible for an application to connect 
> a microphone or a camera in one browser to the speaker or screen of 
> another browser. getUserMedia is an increasingly popular API that 
> Microsoft has been prototyping and that is applicable to a broad set 
> of applications with an HTML5 client, including video authoring and 
> voice commands.
>
> You can find this proposal at:
>
> http://html5labs.com/cu-rtc-web/cu-rtc-web.htm
>

Received on Tuesday, 7 August 2012 06:49:04 UTC