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

Iñaki Baz Castillo <ibc@aliax.net> Wed, 19 June 2013 17:21 UTC

Return-Path: <ibc@aliax.net>
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 343F321F9BA5 for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 10:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level:
X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 d27et-TOGGUo for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 10:21:18 -0700 (PDT)
Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 80F3A21F9B86 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 10:21:17 -0700 (PDT)
Received: by mail-qa0-f54.google.com with SMTP id n20so557542qaj.6 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 10:21:17 -0700 (PDT)
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:content-transfer-encoding:x-gm-message-state; bh=skJrqhVWT2lubPaDdyH02KLo+8cEooCSccyQZv9wyBc=; b=AdmO1pLiToe0OwV2VynlPHkQcTaqBbAihn4mSmI5pNScDYQ3buuKVdnz44FD3NkLSn wr2g4KOxbwp5J+Ia/yKDQnBjUPZFFGqlY7iBcvGFP7SkbGohr1zpfTqDPOiVP/ZRw9s5 aRQ3rpl3EKiK5dHcAerET5PbsygMTjtVFxy/eZTJM+bpLPNQtsNLPNsEOtiRGink2lVQ xsDINRf3KED7xsJmu8tmheIc3+/l+A/BWsGpach0dsO6gHqXQkJ/f+zopGPLJPXR5y6q fFjNGY0tw8dgdVwOS5LHuKYQw04QJGy14sZk6Bi+3kyh3vQnpwcxGLZ1iDB4b5cMGBbu i5TA==
X-Received: by 10.229.149.198 with SMTP id u6mr1559920qcv.20.1371662477409; Wed, 19 Jun 2013 10:21:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 10:20:57 -0700 (PDT)
In-Reply-To: <CAJrXDUEcmWDhJ_3sq9W_VS=KvS3TxB1uPMBBm1W5GoPs=PrpMQ@mail.gmail.com>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com> <CAHp8n2m4VwkpbdGE+q73qqij5RDCB4Vb-Ui1LmGSx1zmv8TX2g@mail.gmail.com> <CAJrXDUEfdsZJBgkcb=MJnxRmk9ZMTHw39DE=YWa+ngXxvfsQ0A@mail.gmail.com> <51C1D55D.6040905@hookflash.com> <CAJrXDUEcmWDhJ_3sq9W_VS=KvS3TxB1uPMBBm1W5GoPs=PrpMQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Wed, 19 Jun 2013 19:20:57 +0200
Message-ID: <CALiegf=q5c=mw9=mCz0nM=TxRZXySbNM=SmQ4Ai1CTH=eRc05A@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnFB8jIzbgzIdnnWvZvB2RuuFwGTFOTiHGLffAq37orNNLEWRyO9QMSLsF5MpSVnKJl89QN
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:21:19 -0000

2013/6/19 Peter Thatcher <pthatcher@google.com>;

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


You base your proposal on the fact that SDP is here forever and must
be used in WebRTC, and then propose some new API methods along with
*lot* of SDP JS parsing/mangling/hackery to mitigate the API
limitations.

While it could be the best we have for now, IMHO it is still a hack or
workaround to just circumvent the real problem and the real
limitation.

Things can be done much better if we remove SDP from the equation.


Best regards.



--
Iñaki Baz Castillo
<ibc@aliax.net>;