Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability

Matthew Kaufman <matthew.kaufman@skype.net> Mon, 06 August 2012 21:52 UTC

Received-SPF: pass (mail144-co1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ;
From: Matthew Kaufman <matthew.kaufman@skype.net>
To: Justin Uberti <juberti@google.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Thread-Topic: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability
Thread-Index: AQHNc/KKtNgifpdI6EiCHb2fk+96dZdNBqGAgAAkhgCAAAk+gIAABVaAgAAS5nI=
Date: Mon, 06 Aug 2012 21:51:55 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A4840E4C90A9@TK5EX14MBXC273.redmond.corp.microsoft.com>
References: <53223349-A31F-4381-899F-82E29B0A0B6C@cisco.com> <CACHLvecT1AgJRo=xM5AH-fGZn+iYrtHqWk7Eym8QJn9U7YGcsg@mail.gmail.com> <CAPk5xQv_ZNqo66LfApshWtRrvXuBMscnp3+kY_GMiibgD1BCqw@mail.gmail.com> <AEF5DA45-0307-4170-A8B4-BAE6B25248C8@cisco.com>, <CAOJ7v-093zyfumK_z5dGhr8msNatfBABk6wD=g80GH2LG4055Q@mail.gmail.com>
In-Reply-To: <CAOJ7v-093zyfumK_z5dGhr8msNatfBABk6wD=g80GH2LG4055Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability
Precedence: list

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Justin Uberti [juberti@google.com]:

> In fact, I think the primary novel features of this proposal are:
>
> - SessionDescriptions are true objects, instead of wrappers around SDP

More important, there is no SDP Offer/Answer state machine within the browser. A developer who desires SDP Offer/Answer semantics may implement that in Javascript or server-side. This is as opposed to JSEP, which includes a particular SDP O/A state machine within the browser, thus requiring it to be interoperable with other SDP O/A state machines both within other vendor browsers as well as existing SIP+SDP equipment and software.

> - Additional control over the ICE Agent
>
> However, no use cases have yet been outlined that require this functionality.

I believe that there are several use cases, including interoperability use cases, where our proposed solution is more likely to be able to meet all edge cases.

An example would be recovery from call setup in the face of a browser page reload... a case where the state of the browser must be reinitialized, leading to edge cases where it becomes impossible with JSEP for a developer to write Javascript that behaves properly in all cases (because without an offer one cannot generate an answer, and once an offer has been generated one must not generate another offer until the first offer has been answered, but in either case there is no longer sufficient information as to how to proceed). While SDP O/A is a useful abstraction for trunk interconnection of peer endpoints, we do not believe it is a good choice for the Javascript API surface.

Likewise, baking in one ICE implementation is likely to lead to interoperability failures when it is found that it has subtle incompatibilities with other deployed applications, whereas our proposal would allow the developer of the web site or supporting Javascript library to code around these issues once RTC-capable browsers are already fielded.

In addition to these differences that fall out of not baking in the full ICE and SDP O/A state machines, our proposal provides several other capabilities, including hooks that allow a developer to customize their application's response to changing network conditions... an area which is currently completely unaddressed in the current WebRTC draft.

I wouldn't be surprised if the existing use-case document(s) is (are) inadequate to describe situations where, for instance, a developer might wish to prioritize video quality over frame rate, or drop video in order to continue audio, but that just means that we all need to provide more input on those documents as well.


Matthew Kaufman

[rtcweb] Microsoft tells W3C and IETF what we are… Cullen Jennings (fluffy)
Re: [rtcweb] Microsoft tells W3C and IETF what we… Luca De Cicco
Re: [rtcweb] Microsoft tells W3C and IETF what we… Rohit Puri
Re: [rtcweb] Microsoft tells W3C and IETF what we… Harald Alvestrand
Re: [rtcweb] Microsoft tells W3C and IETF what we… Cullen Jennings (fluffy)
Re: [rtcweb] Microsoft tells W3C and IETF what we… Justin Uberti
Re: [rtcweb] Microsoft tells W3C and IETF what we… Rohit Puri
Re: [rtcweb] Microsoft tells W3C and IETF what we… Kevin P. Fleming
Re: [rtcweb] Microsoft tells W3C and IETF what we… Jim Barnett
Re: [rtcweb] Microsoft tells W3C and IETF what we… Kevin P. Fleming
Re: [rtcweb] Microsoft tells W3C and IETF what we… Randell Jesup
Re: [rtcweb] Microsoft tells W3C and IETF what we… Randell Jesup
Re: [rtcweb] Microsoft tells W3C and IETF what we… Matthew Kaufman
Re: [rtcweb] Microsoft tells W3C and IETF what we… Justin Uberti
Re: [rtcweb] Microsoft tells W3C and IETF what we… Martin J. Dürst
Re: [rtcweb] Microsoft tells W3C and IETF what we… Randell Jesup
Re: [rtcweb] Microsoft tells W3C and IETF what we… Alexey Aylarov
Re: [rtcweb] Microsoft tells W3C and IETF what we… Tim Panton
Re: [rtcweb] Microsoft tells W3C and IETF what we… Lorenzo Miniero
Re: [rtcweb] Microsoft tells W3C and IETF what we… Jim Barnett
Re: [rtcweb] Microsoft tells W3C and IETF what we… Anant Narayanan
Re: [rtcweb] Microsoft tells W3C and IETF what we… Harald Alvestrand
Re: [rtcweb] Microsoft tells W3C and IETF what we… Tim Panton
Re: [rtcweb] Microsoft tells W3C and IETF what we… Tim Panton