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

Peter Thatcher <pthatcher@google.com> Tue, 18 June 2013 16:31 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 57CE811E80A2 for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 09:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Level:
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, 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 d6aHXHGUieOI for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 09:31:25 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 87DE021F8E2A for <rtcweb@ietf.org>; Tue, 18 Jun 2013 09:31:25 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id hz11so4216138pad.16 for <rtcweb@ietf.org>; Tue, 18 Jun 2013 09:31:25 -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=m9qItfKTuiNf9BsKXgBw+vK3ZXmPfVZrwwuhvW5wdco=; b=lbIyNsVLf23hX5AhIQcao8TMPSsUYIvpDvUaleH/oa9rH3SEwuUpDLTWBUS8NEtAl9 j0dHrxSjAyX0kfPAEr1ZMy9enW6yvlhvIZ67IG6hGWs+lOLG+2yccKLHF04RJlydzU/N a7TrV1JHMbpW84gvOrsWC8Nws0DKHxdbMjr/riiojoko0WV/QjCvJxXAkWVPL8H3+n8i jZJLcMhcpM53EoYlLBpbIniKc62GtfOVO+nzbLjgs7cB4ARtNbQLNZCq3K5fsniAmjKJ v7qQQEN1q/4LLP04pprnhcXxCQn/OG/8b+6Yy8L/Fqj6ENhwLDBLYgEC5XMa6ajPGslH pM9g==
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=m9qItfKTuiNf9BsKXgBw+vK3ZXmPfVZrwwuhvW5wdco=; b=Jk3KfAlHKssX9pnzYeZaROuXwJ42VMAz5EjGn261Ts3hnXjO3n0VoEh3Nz3viYlywc 1kUMNl3OJF4AOT57cPlr6jW0JeeZEu2StEWF2xC8ZWNgHXa4iw0GzCmQoj70x7o1wSqj /LaCq13crhWtUkT+8jhxARCBW6pRD+soWaZQr1oip1q0zYDAqlmWhye4amHoQjAw5t5j OtNmj2w4sk/2A01xnfr9wtLxuvkOfniUp28a7UmSyzAU+Z0cJIH+9fGt6XOcPvIV0Kca LIXyaJvNEUVBGwJ7z2L6iU2/bZHoVLBVidjoe1/8ZGv3iLejldQ7g8disyxWHL8FbUR+ EHPw==
X-Received: by 10.66.122.163 with SMTP id lt3mr2753011pab.219.1371573085155; Tue, 18 Jun 2013 09:31:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.88.8 with HTTP; Tue, 18 Jun 2013 09:30:45 -0700 (PDT)
In-Reply-To: <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C6D46@TK5EX14MBXC273.redmond.corp.microsoft.com>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com> <CABkgnnUmRpanfpwryyiCUsOdMLzrd74n-4LXaj_AK3aLe0yQ8Q@mail.gmail.com> <CAJrXDUGnEwtsGZwUUqQgH0vDnMPy=XxqwQB9fpNcW9yQDhFt4w@mail.gmail.com> <CABkgnnVghXLu0ZdNkBkvLkqr=xgx6irWnyebU6rv+D45M+iaUg@mail.gmail.com> <CAJrXDUFkdfE2gfkRx6im3qNwjd3ObNv0tGO8O0vht146+A1kfQ@mail.gmail.com> <CALiegfmMWiEZDL4eCc6VSEsH1z8F6K5Xzz_-Z6hiKiD9yAap0Q@mail.gmail.com> <51C0269B.5070200@telecomitalia.it> <51C069CD.6000804@hookflash.com> <CALiegf=uENdToGPr1eRRgCOHY6kvoEy8-Aja8mhGWSp0Q=4D8w@mail.gmail.com> <AE1A6B5FD507DC4FB3C5166F3A05A4841A2C6D46@TK5EX14MBXC273.redmond.corp.microsoft.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Tue, 18 Jun 2013 09:30:45 -0700
Message-ID: <CAJrXDUFXjZfyQj6__7WQEGD+_SKD5hTYWzFgsneOwGfO7z1aWg@mail.gmail.com>
To: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
Content-Type: multipart/alternative; boundary=047d7bf1604886499e04df703edc
X-Gm-Message-State: ALoCoQnvbFBJYHyVgDVNP6rMxWA5ZmVE4020usABVQ041JU25ZswbnAOr9f4msQa+LPW1bP3hczU0J7w/++kkZHMlOKx1wG3wF3tm46Ezx0hWAqDCZ74EHJSKXyJkBnQC6KsaMJOBrKsMq5KbnE1UTZb3s+O4Imi8NFyV4YLgCACf1PxN+fvhyW/4GaOibpCnW6EVAcQ3KjF
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: Tue, 18 Jun 2013 16:31:26 -0000

Matthew, please keep this thread focused on what we have proposed.   We're
proposing a way to (optionally if the JS chooses)
send and receive streams in way that doesn't require O/A or SDP.  The JS
can choose to use O/A for adding streams, but our proposal would give JS
more control and flexibilty for adding streams.  But replacing the
mechanism for establishing a transport is not part of what we are
proposing.  And blowing up all of the WebRTC API is explicity not part of
our proposal.  If you want to discuss that, please start another thread.






On Tue, Jun 18, 2013 at 8:43 AM, Matthew Kaufman (SKYPE) <
matthew.kaufman@skype.net>; wrote:

>  It isn't SDP that's the problem. It is the offer/answer semantics.
>
>  Here's a real simple example of the problem: If I have a web browser
> that can do RTP A/V, I should be able to send a form post or XHR to ask my
> security camera to start streaming me RTP video to a specific address and
> port. The browser doesn't need to do ICE connectivity tests, because it is
> only going to receive video.
>
>  I should be able to use a few lines of JavaScript to initialize the
> UDP/RTP receive port and wire it to a video window, set up the codec
> mapping, and ask it for its local address and port so I can tell the camera
> where to send things. But that isn't how it works at all. Instead I need to
> run, in JavaScript, the entire offer/answer exchange from the security
> camera's point of view, extract the relevant information from the SDP blob,
> and then send it off. (Never mind that I also need to have DTLS-SRTP added
> to my camera, even though I'm sending unencrypted RTP from it all over the
> rest of my LAN to other receivers that aren't browsers)
>
>  Same thing if I have a two-way radio system that can talk RTP and ICE
> and which has its own proprietary way of setting up connections... again,
> need to write a whole SDP parser *and* state machine to run the "fake"
> offer/answer exchange.
>
>  Pain. In. The. Ass.
>
>  Matthew Kaufman
>
>  ------------------------------
> *From:* rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of
> Iñaki Baz Castillo [ibc@aliax.net]
> *Sent:* Tuesday, June 18, 2013 7:48 AM
> *To:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple
> sources without encoding them in SDP)
>
>   2013/6/18 Robin Raymond <robin@hookflash.com>;
>
>> SDP is clearly the WRONG technical choice. It was wrong from the start
>> but I think there was a great misunderstanding that it was required or SIP
>> wouldn't be compatible with WebRTC. Since the strong majority at the table
>> were SIP guys because they are the "established" industry it became the
>> 'way to do it' despite how horrible it is for the future. So here we are
>> today...
>
>
>
> Dear WG Chairs,
>
>  With all due respect, IMHO there is enough material to reopen the "SDP
> or not SDP" debate so I would like to request it to the WG.
>
>  I would also appreciate that those in favour of mandating SDP as the
> core communication for WebRTC explain their rationale again (given the
> number of arguments against SDP and the frustration SDP is causing), and
> also that they give arguments and responses to all the SDP related issues
> exposed in this thread, that are nicely summarized in this mail:
>
>    http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html
>
>
>  Really thanks a lot.
>
>
>  --
> Iñaki Baz Castillo
> <ibc@aliax.net>;
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>