IETF Logo Mail Archive

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> Fri, 19 July 2013 14:33 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 C2E4311E82A8 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 07:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.886
X-Spam-Level:
X-Spam-Status: No, score=-4.886 tagged_above=-999 required=5 tests=[AWL=1.713, 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 wIC+yQrP2Sta for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 07:33:31 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id A012311E82B1 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 07:33:26 -0700 (PDT)
Received: from mail16-co9-R.bigfish.com (10.236.132.249) by CO9EHSOBE008.bigfish.com (10.236.130.71) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 14:33:24 +0000
Received: from mail16-co9 (localhost [127.0.0.1]) by mail16-co9-R.bigfish.com (Postfix) with ESMTP id 863C54E013E; Fri, 19 Jul 2013 14:33:24 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI
X-SpamScore: -23
X-BigFish: VS-23(zz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h1de096h8275bh8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail16-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=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail16-co9 (localhost.localdomain [127.0.0.1]) by mail16-co9 (MessageSwitch) id 1374244402969490_28975; Fri, 19 Jul 2013 14:33:22 +0000 (UTC)
Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.230]) by mail16-co9.bigfish.com (Postfix) with ESMTP id E8C453C004D; Fri, 19 Jul 2013 14:33:22 +0000 (UTC)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 19 Jul 2013 14:33:22 +0000
Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0136.001; Fri, 19 Jul 2013 14:33:21 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
Thread-Index: AQHOg8lEAmJsw3Rn2keEWtVFIdVKqplqpyqAgACEKQCAAOZZhQ==
Date: Fri, 19 Jul 2013 14:33:20 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A48423715D23@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>, <CAHp8n2n048GYWvHFNn7eDH6qeBe+hY+q+QcCiztBzzMNbJ8Muw@mail.gmail.com>
In-Reply-To: <CAHp8n2n048GYWvHFNn7eDH6qeBe+hY+q+QcCiztBzzMNbJ8Muw@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: 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: Fri, 19 Jul 2013 14:33:36 -0000

You say... "But I see the full definition of the SDP
parameters that browsers have to support as less important and
potentially just a by product of creating the higher level APIs."

But I'm afraid that as a browser vendor, I will need exactly such a specification in order to create an interoperable browser without looking at the other browser vendors' source code.... so even if your conclusion is correct, we can't avoid this step unless we also abandon SDP as one of the API surfaces.

Matthew Kaufman

________________________________________
From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Silvia Pfeiffer [silviapfeiffer1@gmail.com]
Sent: Thursday, July 18, 2013 5:46 PM
To: Martin Thomson
Cc: <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 Fri, Jul 19, 2013 at 2:53 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> 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


This captures exactly the kind of questions and concerns I had. Excellent work!

However, I don't fully agree with the conclusion of the slide deck.
I'd prefer we extended the constraints and other browser APIs that set
the SDP parameters rather than (or: in preference to) fully specifying
what SDP the browser has to support. I do like the ability to get the
low-level access to mangle the SDP as a means of experimenting with
new functionality or as a means to try and connect to devices that
don't have a WebRTC API. But I see the full definition of the SDP
parameters that browsers have to support as less important and
potentially just a by product of creating the higher level APIs.

What does it take for us to get focused on defining such an API that
is independent of SDP for the JS developer, and for now requires
browsers to do the mapping to SDP for them? Is the extension of the
constraints that a JS dev can manipulate enough for this?

Silvia.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

v2.27.8 | Report a Bug | By Email | System Status