Re: Microsoft API Proposal

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