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

Peter Thatcher <pthatcher@google.com> Thu, 27 June 2013 05:02 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 32B2221F9B41 for <rtcweb@ietfa.amsl.com>; Wed, 26 Jun 2013 22:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level:
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, 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 sotLpgHO60rg for <rtcweb@ietfa.amsl.com>; Wed, 26 Jun 2013 22:02:13 -0700 (PDT)
Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 789CF21F9B40 for <rtcweb@ietf.org>; Wed, 26 Jun 2013 22:02:13 -0700 (PDT)
Received: by mail-pb0-f42.google.com with SMTP id un1so396139pbc.1 for <rtcweb@ietf.org>; Wed, 26 Jun 2013 22:02:13 -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=q9yyBKx9UGxG/WaB/QUXp/c6SjeE9H2nw/0zOs6sgpM=; b=iAjY44d1uG/QvbCp08Ff3pmAwa74FULCfjO4w4NWvcIqmGhaCoG1vIQsaheFHnL/NM u+DTAVLaODR/RC3QeeTikHGQ26rrEp7DmIlVqSF0Lf/XinnesRgFBziEiZjmtkDbFEVI 9ade8CrD/kJLESjYEqHNBB1LrMqvTUx1Z2tJTZxbSLCn2wP8T3IwlwSQh+I43aO34Tse bfIAEo9aVsjux7GXQ71xiPEwE/QZxL8Kuziuc2urcGFvvakULWZBWMEmbyfUXSRjA25G SBaOrcNLJ3lCWV85nLyT2vovzCjyVeLPq56wQuFnyy09iSeUox0r2bDsHZlPT8o8EP7F 9nnQ==
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=q9yyBKx9UGxG/WaB/QUXp/c6SjeE9H2nw/0zOs6sgpM=; b=B3sm4YkDYwOj4vZ6mIdILViauY2usRc/0VYcS98DCAFnlV5w77FpSS76xb+SB/PXlM uUyM/wth7Ny6eyd+2MfEiN/JEa9gOtg5UjrAY+qhK0tIpcervRfBzJ36HSLlTsYqka/M u+IlS0jaKBJ+b9UBjyQzC76fIY3aMcrnv3An3iS9LZxigwN6aMfNUvc6469/lMlmb6X0 OMy88vCSi9AILDYQ4kiYiamMNsqWFccB7ZcGcqAPbQHcxngJJlhNgqLqe3Zj8+wR8K5S suSrUxbxnsC/0k6X/ZVWs5tzFraLC75oThZrTz1iwF9FkT6FUMozS9FetvDBvg4I1jBc 3HxA==
X-Received: by 10.68.134.103 with SMTP id pj7mr4109539pbb.171.1372309333151; Wed, 26 Jun 2013 22:02:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 22:01:33 -0700 (PDT)
In-Reply-To: <BLU403-EAS148552B821ED225C03D441D93750@phx.gbl>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com> <CABkgnnUmRpanfpwryyiCUsOdMLzrd74n-4LXaj_AK3aLe0yQ8Q@mail.gmail.com> <51BF5F00.90705@jitsi.org> <CABkgnnWTvJYG1_HQWz3pZw633rgadeKzx472MTzzFMuq073RgQ@mail.gmail.com> <CALiegfkZcXrNR3CXY--d4ObZMV2z7NEpgdyVHtVtROVtDQsT6A@mail.gmail.com> <CAD5OKxs95gAmYoCr-EB6LaDFW7vaFfpF7=9fu_aCfV=LjwsVpg@mail.gmail.com> <BLU169-W13367E5FDE396829D364D62938C0@phx.gbl> <CAJrXDUEO-prozZPYAm2snfgUXhS5nKRN-ZXWdU1VGfXGnOTAfg@mail.gmail.com> <BLU403-EAS148552B821ED225C03D441D93750@phx.gbl>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 26 Jun 2013 22:01:33 -0700
Message-ID: <CAJrXDUEbD7PuKkwF-oDOZJ-7gWr=GR0sft39t_0_5vDHs9YWOQ@mail.gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: multipart/alternative; boundary=047d7b10cb235344cd04e01baa4d
X-Gm-Message-State: ALoCoQlyTyUEkrkBJrQUAfnI7zco1D+8+pcet3tbb13wdeY+0NwHec7xAo354Y9cK7Ye/Q060ytjmX5jLH8Z0+QlFmMKnfmeQIFtN+z597cBMd6hp+/dSA8TxgJurQOqgeppWI8GdOI3LbMQhS/0r2GwiiyLlYMkkPWjl9evAWO9POVCCUsEuF0GYqxqYaJV8BQ2ViSI/vB0
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: Thu, 27 Jun 2013 05:02:14 -0000

If Node.js wants a cleaner API, it's can certainly create one.  It's not at
all constrained by what goes in the browser or what the WGs decide.  In
fact, that would be an interesting way to explore a cleaner API to see how
well it works.


On Wed, Jun 26, 2013 at 5:19 PM, Bernard Aboba <bernard_aboba@hotmail.com>wrote:

> I do think No Plan represents progress toward containing the SDP monster
> in WebRTC 1.0, particularly for video scenarios. However, I also agree with
> Robin's arguments against SDP and O/ A, particularly for a server-side API
> (e.g. Node.js modules) where the current API makes no sense at all. So my
> perspective is to contain the monster in 1.0, then go with 2.0 first on
> server, then on the browser.
>
> On Jun 17, 2013, at 10:34 PM, "Peter Thatcher" <pthatcher@google.com>;
> wrote:
>
> I like your comparison to the data channels.  As I just pointed out in
> another email, I think it was good that we "contained the SDP monster", as
> you put it, with createDataChannel.  One of the purposes of
> createLocalStream/createRemoteStream is to allow a JS app, if it chooses,
> to "contain the SDP monster" when adding media streams.  It would still be
> needed for setting up the PeerConnection's transport (a monster container
> for a future day perhaps), but that's still significant progress in my
> book, and it does so with simple additions to the PeerConnection that don't
> attempt to blow up the WG.
>
>
> On Mon, Jun 17, 2013 at 5:14 PM, Bernard Aboba <bernard_aboba@hotmail.com>wrote:
>
>>
>>
>>
>> 2) Dissadvantages of using SDP in WebRTC.
>>
>>
>> Roman said:
>> "An unmanageable monster was created which currently stays in the way of
>> developing new functionality (bundle), building applications (does not
>> provide obvious ways to implement obvious tasks, like adding an extra
>> stream without re-negotiating all the existing ones) and even interop with
>> existing SIP endpoints (which was the original but now is complicated since
>> it would require a non trivial set of constraints and subsequent SDP
>> manipulation)."
>>
>> [BA] Hard to argue with this, but I would point out that by far the
>> ugliest part of the monster is the video hindquarters.  While one could
>> argue that we have been living with the warts of SDP for audio and
>> therefore know the workarounds, with video there are substantial
>> interoperability issues, *even among vendors who utilize the same
>> codec*, sometimes even in relatively basic scenarios (e.g. P2P video call
>> with H.264/SVC).  So the "multivendor legacy of interop" just doesn't exist
>> yet (at least, based on standards).
>>
>> So as I see it, it does represent progress that we have contained the SDP
>> monster's impact on the  the data channel, and I welcome Peter's effort to
>> enable applications who don't care about SDP to minimize its usage even if
>> it is not eliminated entirely.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>