Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Thu, 18 July 2013 22:40 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 67BF321E80F7 for <rtcweb@ietfa.amsl.com>; Thu, 18 Jul 2013 15:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599]
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 oeO-dzsgsWQv for <rtcweb@ietfa.amsl.com>; Thu, 18 Jul 2013 15:40:40 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 91DCA11E81E3 for <rtcweb@ietf.org>; Thu, 18 Jul 2013 15:40:39 -0700 (PDT)
Received: from mail77-db9-R.bigfish.com (10.174.16.229) by DB9EHSOBE004.bigfish.com (10.174.14.67) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 22:40:38 +0000
Received: from mail77-db9 (localhost [127.0.0.1]) by mail77-db9-R.bigfish.com (Postfix) with ESMTP id 71F462E029F; Thu, 18 Jul 2013 22:40:38 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI
X-SpamScore: -26
X-BigFish: VS-26(zz98dI9371I15bfK148cIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h1de096h8275bh8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail77-db9: 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=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail77-db9 (localhost.localdomain [127.0.0.1]) by mail77-db9 (MessageSwitch) id 137418723612056_12888; Thu, 18 Jul 2013 22:40:36 +0000 (UTC)
Received: from DB9EHSMHS006.bigfish.com (unknown [10.174.16.244]) by mail77-db9.bigfish.com (Postfix) with ESMTP id F1AB426004B; Thu, 18 Jul 2013 22:40:35 +0000 (UTC)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS006.bigfish.com (10.174.14.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 18 Jul 2013 22:40:33 +0000
Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0136.001; Thu, 18 Jul 2013 22:40:15 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Martin Thomson <martin.thomson@gmail.com>, Peter Thatcher <pthatcher@google.com>
Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
Thread-Index: AQHOg8lEAmJsw3Rn2keEWtVFIdVKqplqpyqAgABd14I=
Date: Thu, 18 Jul 2013 22:40:14 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A4842371513C@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> <CAJrXDUHHVfyE2bCaQu3pR4F=XHvEp64xMwwdRy586FkrOjO3dw@mail.gmail.com>, <CABkgnnXE3mzb=TmiMBWGPwux2vZo3VL14yrQLyPT72hs74b1JA@mail.gmail.com>
In-Reply-To: <CABkgnnXE3mzb=TmiMBWGPwux2vZo3VL14yrQLyPT72hs74b1JA@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.37]
Content-Type: text/plain; charset="us-ascii"
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: "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] 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: Thu, 18 Jul 2013 22:40:46 -0000

Thanks for digging this up... in the meantime of course there's been work ongoing in the MMUSIC IETF WG that adds even more questions than it answers. See messages from as recent as today about msid, bundle, "unified plan", etc. (All useful work that is needed for other types of SDP-using applications, like SIP-based videoconferencing systems, but work that will take some time and which as long as we stick with SDP as an API will be holding up the WEBRTC specification)

As long as it is allowed for the SDP to be modified between createOffer and setLocalDescription, there must be a W3C specification instructing browser vendors as to what changes are and are not allowed. That is *in addition* to knowing what SDP should be accepted (and what it means) when it comes from the other side. And the more "special" stuff ends up in SDP as a result of this WEBRTC-driven MMUSIC work, the longer it will be before such a specification can possibly be complete. (And note that it isn't sufficient to just wait for the MMUSIC work to be done and point to it... it will still be necessary to *write down what the browser must do* in a the W3C specification.)

Or, as I've pointed out before, we could define a browser API that is entirely independent of SDP, and allow enough control that JavaScript programmers can arrange objects and set their parameters such that useful SRTP media streams can be sent and received, and then they can write whatever JavaScript they want to create the SDP that is getting defined over in MMUSIC and other places, or not use those specs if they so desire.

Matthew Kaufman

________________________________________
From: Martin Thomson [martin.thomson@gmail.com]
Sent: Thursday, July 18, 2013 9:53 AM
To: Peter Thatcher
Cc: Matthew Kaufman (SKYPE); <rtcweb@ietf.org>;; public-webrtc@w3.org
Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

On 18 July 2013 08:12, Peter Thatcher <pthatcher@google.com>; wrote:
> I believe I began paying attention to the mailing lists after you sent out
> theses slides that you didn't present.  I'm interested in seeing them, and
> while I could dig through archives to find them, if convenient, could you
> please give me a link to the slides?  Thanks.

It wasn't actually November, it was October, which made this harder to
find than I had expected.

http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/0148.html