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

Justin Uberti <> Tue, 07 August 2012 00:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B38BB11E80A5 for <>; Mon, 6 Aug 2012 17:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.443
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mwAt35fGMdF9 for <>; Mon, 6 Aug 2012 17:11:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7450011E8087 for <>; Mon, 6 Aug 2012 17:11:48 -0700 (PDT)
Received: by qcac10 with SMTP id c10so2428417qca.31 for <>; Mon, 06 Aug 2012 17:11:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id cy12mr20743915qab.68.1344298307632; Mon, 06 Aug 2012 17:11:47 -0700 (PDT)
Received: by with SMTP id cy12mr20743899qab.68.1344298307526; Mon, 06 Aug 2012 17:11:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Aug 2012 17:11:27 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Justin Uberti <>
Date: Tue, 7 Aug 2012 02:11:27 +0200
Message-ID: <>
To: Matthew Kaufman <>
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\)" <>, "" <>, "" <>
Subject: Re: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Aug 2012 00:11:50 -0000

On Mon, Aug 6, 2012 at 11:51 PM, Matthew Kaufman

> From: [] on behalf of
> Justin Uberti []:
> > 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