Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Peter Thatcher <pthatcher@google.com> Wed, 19 June 2013 18:26 UTC

Return-Path: <pthatcher@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 2B0A621F9E11 for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 11:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 yNXIzurpM0uw for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 11:26:56 -0700 (PDT)
Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8777F21F9CFA for <rtcweb@ietf.org>; Wed, 19 Jun 2013 11:26:56 -0700 (PDT)
Received: by mail-pb0-f41.google.com with SMTP id rp16so5387853pbb.28 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 11:26:56 -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; bh=ppDRZv9b3lDdaTYIX0fsBmF/s0bX0F6lr2XAR22euHM=; b=f4rA5mPdXqmQj1HOMUe9fNnW8uVn8A0VcfbCy8jJ2oUkkm3cANLy05NSq63WMl3IhR IeFBiLjuaTL28RujoTjDX+Aprb4yVz85abjya6sMfVZVJIQlqBvticGYPNz0atQmYaNE dOH+EmDpQDP06IUfiNt0sIxm2YZOF+C2+QMEkzeDeXJDOqSvtZGbwuyRtS2jsxCzedmL EZHDeRVhKZgCPjdxXXCJZRmdzHRH0GJjD7eKb6dd1owtKO7Kx7R0MMPz6P5Jb/1VBTvk wkELKMk0NTRz1gTcUbuH3F/CI/WjJxnHW7vz6ZYLE6O7xLdwciA+FT/gwb90Mbhn5MHE PTjQ==
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-gm-message-state; bh=ppDRZv9b3lDdaTYIX0fsBmF/s0bX0F6lr2XAR22euHM=; b=hThiISI6ucQN5VHFIoBQyXkE96aJdxojD4XTaDts2QaA1gCSbhL/IVcngtIJGPBYAt CgkXSb4UBjvdBnhycE9WtxguGGczZOf1iif6hxx0ciU8QVlmtblKDx1Vadqpi7ai7/Ir Yxm4irHLLF5cValfGCJZFHPrDZOxhpIG6RRY7ZHJGsGFeTn8yclxdVtxJ0djhr1CFfny WWc9kXpI4LEqe7Khn64xGei3ux8MWzna4oEx/WAvyLbMBNdNf/+I8rz+S97L99O3SE0X MtksugmtBG3HYwT90yCOG+mVelBvhcXoPww0yto/17ilCz0EMCnNV6m/Eb0Z4Vk1sWmC xwZQ==
X-Received: by 10.68.213.231 with SMTP id nv7mr4100336pbc.70.1371666416210; Wed, 19 Jun 2013 11:26:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:26:15 -0700 (PDT)
In-Reply-To: <CABkgnnXjnN4WZA4QB-N3-u_Or5tTt=gjFYbvZj9mWQcdZPA98g@mail.gmail.com>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com> <CAHp8n2m4VwkpbdGE+q73qqij5RDCB4Vb-Ui1LmGSx1zmv8TX2g@mail.gmail.com> <CAJrXDUEfdsZJBgkcb=MJnxRmk9ZMTHw39DE=YWa+ngXxvfsQ0A@mail.gmail.com> <CABkgnnXjnN4WZA4QB-N3-u_Or5tTt=gjFYbvZj9mWQcdZPA98g@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 19 Jun 2013 11:26:15 -0700
Message-ID: <CAJrXDUH_NNfyZrFVsZqbMW=hk795PX_te_Ax0wQhRmrPAohmwQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f923c7a7d40ff04df85f950
X-Gm-Message-State: ALoCoQlrzmT1qH542DFSJX3HUuKdW0gTwZRyT/Grokrh84y9zKzl25OSVCVQzkF9HaY+NMmTOK8vsxkCpBtcHH7RPt/8QaFOrnm+pH6TpzJ279TVD7wN4g2e9cxIOzXIGbPw07vylKBfUJMrt4t+PHKMQZsGslzYBda1EmwFOce1UKYUkbO5klPZDCv8jcmLfP5gbP+g80r8
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
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: Wed, 19 Jun 2013 18:26:57 -0000

On Wed, Jun 19, 2013 at 10:46 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 19 June 2013 08:15, Peter Thatcher <pthatcher@google.com>; wrote:
> > Unfortunately, Microsoft's input seems to be "our way or the highway"
>
> The good thing about this forum is that correcting gross
> misrepresentation is as easy as it is to propagate it.
>

I'll happily be wrong about my representation of Mircosoft's standpoint,
but Matthew just said "My position is that there are no incremental
improvements possible without removing the O/A state machine from the
browser."  That's pretty hardline, with no room for compromise.

But to be fair, I retract my comment of "Microsoft's input seems to be 'our
way or the highway'" and would like to replace it with
 "Microsoft's input seems to be 'no incremental improvements without
removing O/A from the browser'".  How's that?


>
> Microsoft's input is that Offer/Answer is difficult to remove without
> also removing a reliance on SDP at the same time.  CU-RTC-Web is a
> demonstration of one solution to that problem that we believe is
> workable.  That proposal was input, not ultimatum.  We'd be happy to
> consider other alternatives, but we don't believe that any attempt
> that retains both O/A and SDP to be a worthwhile step.
>

I'm fine with the goal of avoiding SDP and O/A.  My proposal that started
this thread does just that for media streams (but not transports).

It's the "no incremental improvements" part that I have issue with.  I
believe we can do this with incremental improvements.



>
> The proposals I've seen for incremental refinement don't successfully
> avoid the SDPNG trap.  Most increase the API surface area, often
> dramatically, which burdens both browser implementations and API
> users.  I personally don't believe it to be possible to avoid this
> problem without tackling the core problem, which unfortunately
> requires a little bit of courage.
>

I disagree.  My proposal eliminates at least half of the pain by only
adding two methods to PeerConnection (and a few dictionaries).  That does
add some burden to the browser, but relieves a lot of burden from the API
users.