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

"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Tue, 18 June 2013 15:53 UTC

Return-Path: <matthew.kaufman@skype.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 D469B21F9A43 for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 08:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level:
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 CqNiRTXREelR for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 08:53:12 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 69E1721F9963 for <rtcweb@ietf.org>; Tue, 18 Jun 2013 08:53:12 -0700 (PDT)
Received: from BN1AFFO11FD009.protection.gbl (10.58.52.203) by BN1AFFO11HUB032.protection.gbl (10.58.52.142) with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 15:43:18 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD009.mail.protection.outlook.com (10.58.52.69) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 15:43:18 +0000
Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.171]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 15:43:13 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
Thread-Index: AQHOa1pL3f2CtN2bTEydXd59L0Jyj5k6QmQAgAAH7oCAACn2AIAAffyAgAAzWgCAAA4dgIAAUBqAgAALU4CAAAehiA==
Date: Tue, 18 Jun 2013 15:43:12 +0000
Message-ID: <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>
In-Reply-To: <CALiegf=uENdToGPr1eRRgCOHY6kvoEy8-Aja8mhGWSp0Q=4D8w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.33]
Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C6D46TK5EX14MBXC273r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377454002)(199002)(479174002)(50986001)(56816003)(6806003)(59766001)(66066001)(55846006)(56776001)(77096001)(49866001)(74706001)(79102001)(69226001)(20776003)(81542001)(51856001)(53806001)(15202345002)(33656001)(31966008)(74366001)(65816001)(81342001)(76482001)(16236675002)(77982001)(63696002)(76796001)(80022001)(47976001)(47736001)(74876001)(54356001)(4396001)(16406001)(71186001)(54316002)(512934002)(74662001)(76786001)(561944002)(46102001)(74502001)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB032; H:TK5EX14MLTC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0881A7A935
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 15:53:18 -0000

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<mailto: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<mailto:ibc@aliax.net>>