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 17:01 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 5CCB621F9DDC for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 10:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.885
X-Spam-Level:
X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.092, 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 lraW5rcBtSgH for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 10:01:52 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7AED521F9DD4 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 10:01:50 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id fa11so5375870pad.19 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 10:01:49 -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=KsvFWiJoCCn6nHYA6v/8xWTPEXjK7x626hlra/ULlYk=; b=BVcBkQ+3gSaJnRMX4bsl/SyzxL3OT5uVokgRsswI9ur4/l54+pkX6VfNwagwMSa4Tn UwLfyOYRBlRiwAeejZZAHpQqoIAlFHvjlQr8Q1NKCY5oqDCnycqDOpUpDGxySQqyS1P8 +KcF/Cwlx+/0Ai6/tETKIhdf+Ae92DDOJKzQ6f8TuhwTMEjGHxc34DzoOiZoxfW8PAtX DxzMtww8nD8OVT9Oygt2LoJP1d/iUdoa6VUayWi9ZIE7SmwDYoRvqLE/LOMn9mJpUsPd jqrOEqNcwh1iPdkcIR5Oy80fDGQEVsq8hYy1hZTpaIFD7+0roP3pMPxvwWmJsAGGLpjJ fIog==
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=KsvFWiJoCCn6nHYA6v/8xWTPEXjK7x626hlra/ULlYk=; b=Xem1Ajqg3Rk6ymbgezoYwz4eosa/2iuOf1W7+2lyCgGyZ3US38NOfEQb6NFqhk1oIa Ph005/QCQNlH96/3LuW85dDLZuBB420ScZOS9mZLOegvXd6pxCqAOx3nefY0D5qaQ8AO 7GS+CsPAguQlsxAI+YTtsk0nAytOi3D+JVcHOzO+Lb3jimYx8lq/MFnD7IHBzgUhbwlq /lbAGd5EDM4IMwrv2bRVwCpDPqxEcm/2yvVqUvRZh5zTkSdbvRQtop4p5QGygyPfnuov lyUz98WvOkef6BssjL9toajusetdZaSnHMjWl3imioOaB+hZf9BOgNCOL7XwFfdvbSZS QmfQ==
X-Received: by 10.66.240.70 with SMTP id vy6mr7785093pac.70.1371661309716; Wed, 19 Jun 2013 10:01:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 10:01:08 -0700 (PDT)
In-Reply-To: <51C1D55D.6040905@hookflash.com>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com> <CAHp8n2m4VwkpbdGE+q73qqij5RDCB4Vb-Ui1LmGSx1zmv8TX2g@mail.gmail.com> <CAJrXDUEfdsZJBgkcb=MJnxRmk9ZMTHw39DE=YWa+ngXxvfsQ0A@mail.gmail.com> <51C1D55D.6040905@hookflash.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 19 Jun 2013 10:01:08 -0700
Message-ID: <CAJrXDUEcmWDhJ_3sq9W_VS=KvS3TxB1uPMBBm1W5GoPs=PrpMQ@mail.gmail.com>
To: Robin Raymond <robin@hookflash.com>
Content-Type: multipart/related; boundary=047d7b15aba91e48a804df84c93d
X-Gm-Message-State: ALoCoQk8tC+fbf0PPxQzsV7UChXT0/l0Jy2ooT++WYxFaHCKZv2Ko0Dj1M7DzWsudHopBgw1aY+50IhSXTvbbnvixly9ONbCNdzorROy2Kt431PwdmbbRxgJzxeVdp+ShV6jBg60Gkc90q1tUrm9ZHlPh9pbsJJZ+kKNBzdBM/GbXbqHa6fnA88IykX121/kZzGSgCqYoFsI
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 17:02:03 -0000

On Wed, Jun 19, 2013 at 8:59 AM, Robin Raymond <robin@hookflash.com>; wrote:

>
> Then why not move to a lower level API and do it as a shim (i.e. reverse
> polyfill)?
>


>
> If provided a lower level API that works without SDP where the individual
> network/media component wiring/attributes can be controlled, we could
> create the same WebRTC API that exists today for people who think "SDP out
> to be enough for anybody" layered on top of it; They lose absolutely
> nothing (in fact they gain a lot since now they can tweak the logic to be
> even more compatible with their networks and dynamically update it as
> needed instead of waiting for the next browser "patch" to be deployed
> everywhere on all platforms). The only different is that it's an JavaScript
> implementation rather than written in C++. They get what they want but we
> get what we need.
>

There are two separate things here: 1.  adding to the current API to allow
JS to avoid SDP.  2.  removing what is there that uses SDP.

You're saying you want to add new things and remove olds things.  But I
think really you just want to add what you want, and it would matter if
what you didn't want to use were still there.  So I think it's better to
talk about what we can add to the API to make it easier to work with rather
than talk about starting from scratch.  Removing the existing pieces would
not be nearly as easy as you make it sound.

That's the difference, they *want* this API as it "works/good enough for
> them", whereas many of *need* a lower level API to do anything
> sophisticated at all.
>

You don't need a lower level API.  SDP munging can get you what you need.
 But what you want is to not have to do SDP munging.

My proposal is to add two methods to PeerConnection that, if optionally
used by JS, will give you what you want for media streams: the ability to
control what is sent and received without SDP munging.  It does not,
however, relieve you from SDP munging on the transport side.  But as I've
pointed out, that's limited to about 10 lines of SDP, so at least it's much
less SDP munging.  Later, once could consider more simple additions that
reduce the need for SDP munging further.


> As it stands, it makes many use cases for us who whom don't want to do
> basic SIP/SDP signaling extremely challenging, complex, ugly, brittle, if
> not outright impossible. I've explained many times why using SDP with
> offer/answer is horribly bad idea (and I can re-share those links if
> needed).
>
>
I think your dislike of SDP is sufficiently clear.


>  -Robin
>
>
>    Peter Thatcher <pthatcher@google.com>;
>  19 June, 2013 11:15 AM
>
>
>
> I hope so as well.  Unfortunately, Microsoft's input seems to be "our way
> or the highway" and the input of others seems to be "SDP ought to be
> enough for anybody".  My thinking is that we can make incremental
> improvements toward a cleaner API without being so extreme at either end.
>  And I hope I can find others that think similarly.
>
>
>