Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Sat, 20 July 2013 03:17 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 4BB1F21F9D75 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 20:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.055
X-Spam-Level:
X-Spam-Status: No, score=-5.055 tagged_above=-999 required=5 tests=[AWL=1.544, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 YAvOSMKsymM1 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 20:17:07 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id E65C621E80B8 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 20:17:06 -0700 (PDT)
Received: from mail132-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.22; Sat, 20 Jul 2013 03:17:05 +0000
Received: from mail132-co9 (localhost [127.0.0.1]) by mail132-co9-R.bigfish.com (Postfix) with ESMTP id 86C3D2C00E0; Sat, 20 Jul 2013 03:17:05 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI
X-SpamScore: -3
X-BigFish: VS-3(zz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097h8275bhz2fh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail132-co9: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=matthew.kaufman@skype.net; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail132-co9 (localhost.localdomain [127.0.0.1]) by mail132-co9 (MessageSwitch) id 1374290202856034_32613; Sat, 20 Jul 2013 03:16:42 +0000 (UTC)
Received: from CO9EHSMHS027.bigfish.com (unknown [10.236.132.245]) by mail132-co9.bigfish.com (Postfix) with ESMTP id C229FC0047; Sat, 20 Jul 2013 03:16:42 +0000 (UTC)
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CO9EHSMHS027.bigfish.com (10.236.130.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 20 Jul 2013 03:16:42 +0000
Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0136.001; Sat, 20 Jul 2013 03:15:43 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Cullen Jennings <fluffy@iii.ca>, Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)
Thread-Index: AQHOhKCbCeL+o/p+XES8EqmiU0dHnZlsvYcAgAAnBoA=
Date: Sat, 20 Jul 2013 03:15:42 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A484237181A5@TK5EX14MBXC266.redmond.corp.microsoft.com>
References: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@mail.gmail.com> <CABcZeBPa4wBS8pYq=0wesMOfL6TkeC7QGAZ8pWwOcnkhkJqWfA@mail.gmail.com> <CAJrXDUFxo8P8wxh8jX3019yPQOuwQ0eVdsFmRXsbWdWinnc5oA@mail.gmail.com> <CABcZeBOTKpmFC34waqZ4kA-P8t+E6yY9gX1JFCHhsBH0+CF-Qw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <CAD5OKxtKLMf_d=8GSMrqfNhDHPe9MFP2ZTKzZHFn9CyMr-gSVQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <CAD5OKxvGfkgRp6tXwbOu_kVteHiBBqsyR5ixH18FMKjCNGO8VQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl> <AE1A6B5FD507DC4FB3C5166F3A05A484213E41E7@TK5EX14MBXC265.redmond.corp.microsoft.com> <C50FDAD5-492C-4A83-AD6D-464242FB4A05@iii.ca> <CALiegfneUj=kzDjR_E1=S-bqAajaPUE3f_A2g8oGriFyPhamPA@mail.gmail.com> <51E96B5B.2050302@nostrum.com> <CABkgnnXa-eTzRHcLMnHam4c+1D9kkvRwi9=V-9P43+p+pKE_sw@mail.gmail.com> <644AB0EE-8889-4940-BA88-33EA653D44DC@iii.ca>
In-Reply-To: <644AB0EE-8889-4940-BA88-33EA653D44DC@iii.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.36]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: skype.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)
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: Sat, 20 Jul 2013 03:17:13 -0000

From: Cullen Jennings [mailto:fluffy@iii.ca]:
> On Jul 19, 2013, at 9:54 AM, Martin Thomson <martin.thomson@gmail.com>;
> wrote:
> 
> > Negotiation is a hole.  A vast, soul-sucking, waste of time.
> 
> That's might be closer to true when you control both ends, like Skype.
> 
> It's not true when a browser from one vendor running an application from a
> scone vendor needs to talk to video conferencing system from a third
> vendor.

If you think that the second vendor's web server + signaling gateway should be doing negotiation between itself and the third vendor's videoconferencing system, then that's fine.

If you think that the second vendor is going to get the first vendor to ship an updated browser to make its SDP O/A 100% compliant with what the third vendor's system is expecting, then you're crazy. It simply isn't going to happen, and what's more, given that the browser from the first vendor contains a complete JavaScript implementation, there's no reason why it should be. The first vendor should provide the JS APIs that are necessary for the second vendor to build the system they want to build. Done. And without the endless pain that trying to make browser SDP O/A compatible with anything else is going to be.

Matthew Kaufman