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

Justin Uberti <juberti@google.com> Tue, 07 August 2012 00:11 UTC

Return-Path: <juberti@google.com>
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 B38BB11E80A5 for <rtcweb@ietfa.amsl.com>; Mon, 6 Aug 2012 17:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.443
X-Spam-Level:
X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 mwAt35fGMdF9 for <rtcweb@ietfa.amsl.com>; Mon, 6 Aug 2012 17:11:48 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7450011E8087 for <rtcweb@ietf.org>; Mon, 6 Aug 2012 17:11:48 -0700 (PDT)
Received: by qcac10 with SMTP id c10so2428417qca.31 for <rtcweb@ietf.org>; Mon, 06 Aug 2012 17:11:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7w0jJQTUbBFje0Usq91tT2UylFYFVZyG0fGJBzgntQU=; b=pDFaig+MvDEs7xY4eCloSp0tJwJMGjrdZK+m8KXcz5wEWiyjOiwLlR4j7j0iI8UCHm GI/zPo5Xce8rVHtx6MdXml3UVX74Jy/druKvpvC2JTSYUHI9NSmAORv1aeInawldZ2Sp PvSArjM8ArBcjUf388y2l1UTcH1eQ+PkTBhtAb98CXzaCFaUzmQ9NlJkIDAGNYJIJu3o 8qgIiQLDDnJGZESI1Vw2azsHj+GvjDgItwNprUVhK0aYXtCIsALP6IjSxq9wmBifVn7p jJRHTRIKZP5iSYdYV6cekLl4XrfHy7ZAAb+BQHIu9zIHKkK1X/cl9BEZoagPBm2Y/8mf sjbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=7w0jJQTUbBFje0Usq91tT2UylFYFVZyG0fGJBzgntQU=; b=Pf9aF747fSVes+t/S08TGmmKKUN5KBrgXOr1DPf23eEC800F9AMtuGxJdK0DyUwQw0 VuYTzUmB2HCOF/MThPhFb8T+lIs8KbFbrnucY7vqHfW0/zqR6QDf/cx/QirbHzp6OfCK BQkfm8pnHjrEmzirj+RWjfY1J1Bn+KkV0Zt4N3dbUApiTpbO1Yw47JuKw2cSKXygl+lJ b3w2pHYcLZCtse/XlI5k52uwHegzq7QKOdI+0R+ZMcot92yZCj34fPIlLeR0cZgMs3HG WFikIAC+2jfXu9lKY8Y7iL1Quh4gdhssEdVXo1vrU8wiqAkF5epVPh85Txca86cN5qlT XcQQ==
Received: by 10.224.188.12 with SMTP id cy12mr20743915qab.68.1344298307632; Mon, 06 Aug 2012 17:11:47 -0700 (PDT)
Received: by 10.224.188.12 with SMTP id cy12mr20743899qab.68.1344298307526; Mon, 06 Aug 2012 17:11:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.218.80 with HTTP; Mon, 6 Aug 2012 17:11:27 -0700 (PDT)
In-Reply-To: <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> <AE1A6B5FD507DC4FB3C5166F3A05A4840E4C90A9@TK5EX14MBXC273.redmond.corp.microsoft.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 7 Aug 2012 02:11:27 +0200
Message-ID: <CAOJ7v-3w+AUR08PtOZgVQJDnswjCsBwd0iPyzpdR8VFy7JYhUA@mail.gmail.com>
To: Matthew Kaufman <matthew.kaufman@skype.net>
Content-Type: multipart/alternative; boundary=20cf30363ebb17a1fd04c6a1d781
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkKJ8+Zrsxi2y6ov9i+mBuCybdBq7rBdNs5y1jGLvgbdpoBq+ETaXt1X8wdl5WRFdsJv/Bpd8kNiHJc0GGbydWUbQ33ucuiqdBjqIO5zZIYHl60og/xXu5OH/gxkDYuwhdod23oHxXU16Vy1vfF2BZIp+wfXsiAPjQN7qqx9LemYPpjWfpp2FT8UtV6NBgfHvE7Jxlf
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "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: Tue, 07 Aug 2012 00:11:50 -0000

On Mon, Aug 6, 2012 at 11:51 PM, Matthew Kaufman
<matthew.kaufman@skype.net>wrote;wrote:

>
> 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.
>

While there is a simple state machine, with JSEP you can drive the state
machine to any state you want, easily. To say that it bakes in SDP
offer/answer is inaccurate; if you don't want to use offer/answer you can
just set the local or remote description at any time (followed by
reapplying the existing remote/local description to complete the sequence).

This could of course be streamlined, but this could be done as an evolution
of the existing API.


> > - 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.
>

As others have pointed out, these kinds of hooks have been discussed but
haven't yet made it into the current API 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
>