Re: Microsoft API Proposal

sorry, I am confused on what an unofficial submission to the w3c is. Is this a submission from the W3C member (in this case Microsoft) or this a random comment sent to a public mailing list. I was under the impression you were the Microsoft representative and emails from you represented the Microsoft position. I'm happy to receive random emails to a public list, but I think you need to be very clear about which this is. 



On Aug 9, 2012, at 8:45 , Martin Thomson wrote:

> I am attaching the specification, with a minor correction to highlight
> that this is unofficial (and not a Member Submission).  Apologies for
> the size.
> 
> --Martin
> 
> On 6 August 2012 12:40, Martin Thomson <martin.thomson@gmail.com> 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
> <realtime-media.html><overview.png>

Received on Saturday, 25 August 2012 13:42:47 UTC