W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2012

Re: Microsoft API Proposal

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 7 Aug 2012 10:21:27 +0200
Message-ID: <5020D007.1030304@ericsson.com>
To: public-webrtc@w3.org

many thanks for this contribution. As you know, the WG already has an 
API proposal that has matured over the last year.

I think it would be helpful (when reviewing) if you could in a more 
concrete way point out the key differences, and the reason why your 
proposal is different.

(You have indicated some reasons, but it is put a bit vague for my taste).


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 08:21:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:29 UTC