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

Return-Path: <matthew.kaufman@skype.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5145321E808E for <rtcweb@ietfa.amsl.com>; Mon, 6 Aug 2012 14:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+5AFUOrhXXj for <rtcweb@ietfa.amsl.com>; Mon, 6 Aug 2012 14:52:01 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9274821E808D for <rtcweb@ietf.org>; Mon, 6 Aug 2012 14:52:01 -0700 (PDT)
Received: from mail144-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Aug 2012 21:52:00 +0000
Received: from mail144-co1 (localhost [127.0.0.1]) by mail144-co1-R.bigfish.com (Postfix) with ESMTP id 9DB0D5000BA; Mon, 6 Aug 2012 21:52:00 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -21
X-BigFish: VS-21(zz1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah)
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 ;
Received: from mail144-co1 (localhost.localdomain [127.0.0.1]) by mail144-co1 (MessageSwitch) id 1344289917826177_1023; Mon, 6 Aug 2012 21:51:57 +0000 (UTC)
Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.244]) by mail144-co1.bigfish.com (Postfix) with ESMTP id C4B20BC0044; Mon, 6 Aug 2012 21:51:57 +0000 (UTC)
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 Aug 2012 21:51:56 +0000
Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.216]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Mon, 6 Aug 2012 21:51:56 +0000
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, 6 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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: skype.net
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
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2012 21:52:02 -0000

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