From ibc@aliax.net Mon Jul 1 02:01:46 2013 Return-Path: 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 360B921F9C6C for ; Mon, 1 Jul 2013 02:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 znOYfS7il95l for ; Mon, 1 Jul 2013 02:01:42 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6156521F9C62 for ; Mon, 1 Jul 2013 02:01:41 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id g10so1882805qah.5 for ; Mon, 01 Jul 2013 02:01:40 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=0FSmxOH2r79LLfT59Zwbc7lVugURlFHhLQASDCgbkWQ=; b=O/IWc0duE1iwQb1s1eNzEtaEbh88sQMovn44wCorZB10ztGVZ1kOWb6uQsoOLAiZYJ KM6MfFKR6uA6q5Amar3R9kxoXf2zEVauL5piJoRFKDrcNQO8xAZ6r9rzHejzMQ/9mByD EYVU465FKxRP+bqWewYzBa+Tt3Qgo9xmn0Kg0UYbPMDw1Zyp1U8wSHRhkW1jzzLcfW/S zmms1z+1YpMetKG3m2zzWR/5cEhvzR+mKIA6Di5v7Kb9kadm3R7xzeGIfOyMV2f3lwai 9BlQe77GGWYcfzcrf1gbcDLRPCiBJ3Rr/AzUVqg/fYEYNLMghexxXoCi2wW8LwR2QcJ+ fApQ== X-Received: by 10.49.82.234 with SMTP id l10mr30325809qey.17.1372669300601; Mon, 01 Jul 2013 02:01:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 1 Jul 2013 02:01:20 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 1 Jul 2013 11:01:20 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmh+Ktej240I/fQBGI2zkKEoGuB86zd420jEvxLvi0TUdYxBtlIUGzNGdbWqZRehtnaQABy Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 09:01:46 -0000 Hi Stefan, 2013/7/1 Stefan H=C3=A5kansson LK : > 4.5: This really underlines the need to specify in detail what the > allowed SDP variations are (or, if we remove SDP, to specify any other > mechanism to exchange the things needed to set up RTP and other things > going on the wire). The draft http://www.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-api-rat= ionale-00.txt clearly proposes that NO media description format is required in the wire. This is not about SDP vs SDP+XML vs SDP-NG. The draft explains (in section 5) why it is not needed to mandate how media info must be sent in the wire. Instead, let the developer to retrieve the media/transport information from the API and send it in the wire in the way it wants. Best regards. -- I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Mon Jul 1 07:11:38 2013 Return-Path: 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 0D35411E81DE for ; Mon, 1 Jul 2013 07:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, 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 qlo+OsFSdadW for ; Mon, 1 Jul 2013 07:11:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 73DFC11E818B for ; Mon, 1 Jul 2013 07:11:32 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-36-51d18e13dc9f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2F.78.19388.31E81D15; Mon, 1 Jul 2013 16:11:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Mon, 1 Jul 2013 16:11:31 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model Thread-Index: AQHOcibV+w71mSCXSkiQxLiPakqfXQ== Date: Mon, 1 Jul 2013 14:11:30 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvra5w38VAgzdnJSym77Ox+N3dwW6x 9l87uwOzx7mG9+we57cuYfJYsuQnUwBzFJdNSmpOZllqkb5dAlfGn9ZWloJ93BULv65kbmBc ydnFyMEhIWAice90ShcjJ5ApJnHh3nq2LkYuDiGBw4wSnb2/2UASQgILGSUeb0oFsdkEAiW2 7lsAFhcRsJS4MfcmM4jNLOAj8WTHV3YQW1jARqLvw2cmkPkiArYS29pYIcr1JOZ8XglWwiKg IrG0A2IMr4CvxP3GN+wQe7czSnyfughsJiPQQd9PrWGCmC8ucevJfCaIQwUkluw5zwxhi0q8 fPyPFcJWkvix4RILRL2exI2pU9ggbG2JZQtfM0MsE5Q4OfMJywRG0VlIxs5C0jILScssJC0L GFlWMbLnJmbmpJebb2IExsbBLb8NdjBuui92iFGag0VJnHez3plAIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYzucZ/Ws8lkKOnFxn48LWK9lZ1pYWBSc9C0FxInFq6WF+wIlJeq/OU3aW03 9/JJcmIr3mx9mZN4IOvYUcu5Vz4suLIt37VeWH9jl3pzZcAcYSbDDKEv4TLbGESTw//zT9iT dZ/NiSn/dybP6xmLHSvObA76YpRoZfpL7I+YvIiSoc7uHYIHupRYijMSDbWYi4oTAdrCHHZb AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 14:11:38 -0000 On 2013-07-01 11:01, I=F1aki Baz Castillo wrote:=0A= > Hi Stefan,=0A= >=0A= >=0A= > 2013/7/1 Stefan H=E5kansson LK :=0A= >> 4.5: This really underlines the need to specify in detail what the=0A= >> allowed SDP variations are (or, if we remove SDP, to specify any other= =0A= >> mechanism to exchange the things needed to set up RTP and other things= =0A= >> going on the wire).=0A= >=0A= > The draft http://www.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-api-r= ationale-00.txt=0A= > clearly proposes that NO media description format is required in the=0A= > wire. This is not about SDP vs SDP+XML vs SDP-NG.=0A= >=0A= > The draft explains (in section 5) why it is not needed to mandate how=0A= > media info must be sent in the wire. Instead, let the developer to=0A= > retrieve the media/transport information from the API and send it in=0A= > the wire in the way it wants.=0A= =0A= I still think my point is valid. If the app i browser A retrieves this =0A= media/transport info using the API, and sends it to the peer app in =0A= another browser B, it must still mean the same for both browsers.=0A= =0A= True, we're struggling with this part for SDP. But removing it and only =0A= have API calls does not get us away from defining exactly what those =0A= calls mean.=0A= =0A= >=0A= >=0A= > Best regards.=0A= >=0A= >=0A= > --=0A= > I=F1aki Baz Castillo=0A= > =0A= >=0A= =0A= From ibc@aliax.net Mon Jul 1 07:28:44 2013 Return-Path: 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 17F8621F9ED9 for ; Mon, 1 Jul 2013 07:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 4086uHVxg2qx for ; Mon, 1 Jul 2013 07:28:37 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6610B11E80E7 for ; Mon, 1 Jul 2013 07:28:37 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so2075330qab.8 for ; Mon, 01 Jul 2013 07:28:35 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=lAfKtoD61d8crE5w8vnEguDZDClUxkPKz6SVnWxVOBw=; b=OSpgvN/2SpyIxFFrLD9W1bFSJsDF5wMDVLNBiSH6s4OJS8O84s9Aq5O9lHjDzGInub QQ1oUFAjpXxu+xRhLBbxU/86v9oMcXeYoKG/rLlQDcnD632bdh56O+rusMSbeICHLy0n +tWavbIQCZ9VxbVl4hd0obS0IS80IfO4kbzkDHJV0/ATdQBU433mCQOYmZ6iAHmt8Y4p OKHOCz9ZsfLCQ+KKLGAzsRTmB8mZCg7jijwzZ/BlGtHQJAuKboH2SVWoGBmoGq86k7x5 77G9v2xWrrzM5MKrccqRUb+oKBfJhTetajzgckfhoZ4uBhQnM/qs7Uma0xWT0a8/dEGp H8ew== X-Received: by 10.224.92.79 with SMTP id q15mr14109842qam.104.1372688915797; Mon, 01 Jul 2013 07:28:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 1 Jul 2013 07:28:15 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 1 Jul 2013 16:28:15 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmkwupGBfK7pt0QDhZFp/zdvu77a3H1r3uZVoAqoyCF/Q1k29Izewsj8Ux1yrJqadOKbAzt Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 14:28:44 -0000 2013/7/1 Stefan H=C3=A5kansson LK : >> The draft explains (in section 5) why it is not needed to mandate how >> media info must be sent in the wire. Instead, let the developer to >> retrieve the media/transport information from the API and send it in >> the wire in the way it wants. > > I still think my point is valid. If the app i browser A retrieves this > media/transport info using the API, and sends it to the peer app in > another browser B, it must still mean the same for both browsers. > > True, we're struggling with this part for SDP. But removing it and only > have API calls does not get us away from defining exactly what those > calls mean. Stefan, the media/transport info will be sent from browser A to browser B using the custom format the developer of the website chose, period. I don't understand why you think that the format of the media/transport info must be constant/fixed for any website using WebRTC. It makes no sense IMHO. That is up to the website developer. -- I=C3=B1aki Baz Castillo From BeckW@telekom.de Mon Jul 1 08:00:44 2013 Return-Path: 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 5134111E811F for ; Mon, 1 Jul 2013 08:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 52kg3Nv4OWGx for ; Mon, 1 Jul 2013 08:00:38 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8195911E80D7 for ; Mon, 1 Jul 2013 08:00:37 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 01 Jul 2013 17:00:35 +0200 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.13]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 1 Jul 2013 17:00:35 +0200 From: To: , Date: Mon, 1 Jul 2013 17:00:34 +0200 Thread-Topic: [rtcweb] WebRTC service between SPs Thread-Index: Ac50szvNguxJUjrOSEG4KWKY26t8fQBtu+4w Message-ID: References: <034C870DB898BE43B5787C7A79107CD94BFA4E1B@nkgeml507-mbx.china.huawei.com> <57A15FAF9E58F841B2B1651FFE16D281052E6B@GENSJZMBX01.msg.int.genesyslab.com> <034C870DB898BE43B5787C7A79107CD94BFA5254@nkgeml507-mbx.china.huawei.com> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_AAE428925197FE46A5F94ED6643478FEAC99A4C7C6HE111644EMEA1_" MIME-Version: 1.0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC service between SPs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 15:00:44 -0000 --_000_AAE428925197FE46A5F94ED6643478FEAC99A4C7C6HE111644EMEA1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91ciBXRUJSVEMgc2VydmljZSBhY2NlcHRzIDNyZCBwYXJ0eSBhdXRoIGZyb20gR29vZ2xl LCBGQiwgVHdpdHRlciwgYSAqbG90KiBvZiBwZW9wbGUgY2FuIHVzZSBpdCBhbmQgeW91IGRvbid0 IGhhdmUgdG8gd29ycnkgYWJvdXQNCmxlZ2FjeSBpbnRlcmNvbm5lY3Rpb24gY29uY2VwdHMgdXNp bmcgU0lQIG9yIFhNUFAuIFRoZXJlIGlzIG5vIGxvbmdlciB0aGUgbmVlZCBmb3IgYSBzaW5nbGUs IGdsb2JhbCBzaWduYWxsaW5nIHByb3RvY29sIHRoYXQgY292ZXJzIGFsbCBwb3NzaWJsZSB1c2Ut Y2FzZXMuIFdlIG9ubHkgbmVlZCBhIHdheSB0byBhdXRoZW50aWNhdGUgY2FsbGVycywgYW5kIHBl cmhhcHMgdGhlaXIgVVJMIHRvIHJlYWNoIHRoZW0gZm9yIGEgcmV0dXJuIGNhbGwuIEJvdGggY2Fu IGJlIGRvbmUgd2l0aCAzcmQgcGFydHkgYXV0aGVudGljYXRpb24gcHJvdG9jb2xzLiBUb2RheS4N Cg0KDQpSZWdhcmRzLA0KV29sZmdhbmcgQmVjaw0KDQoNCkRldXRzY2hlIFRlbGVrb20gVGVjaG5p ayBHbWJIDQpGaXhlZCBNb2JpbGUgRW5naW5lZXJpbmcgRGV1dHNjaGxhbmQNCldvbGZnYW5nIEJl Y2sNCkhlaW5yaWNoLUhlcnR6LVN0cmHDn2UgMy03LCA2NDI5NSBEYXJtc3RhZHQNCis0OSA2MTUx IDU4MSAyODMyIChUZWwuKQ0Kd3d3LnRlbGVrb20uZGU8aHR0cDovL3d3dy50ZWxla29tLmRlLz4N Cg0KRXJsZWJlbiwgd2FzIHZlcmJpbmRldC4NCg0KRGV1dHNjaGUgVGVsZWtvbSBUZWNobmlrIEdt YkgNCkF1ZnNpY2h0c3JhdDogRHIuIFRob21hcyBLbm9sbCAoVm9yc2l0emVuZGVyKQ0KR2VzY2jD pGZ0c2bDvGhydW5nOiBEci4gQnJ1bm8gSmFjb2JmZXVlcmJvcm4gKFZvcnNpdHplbmRlciksIEFs YmVydCBNYXRoZWlzLCBLbGF1cyBQZXJlbg0KSGFuZGVsc3JlZ2lzdGVyOiBBbXRzZ2VyaWNodCBC b25uIEhSQiAxNDE5MA0KU2l0eiBkZXIgR2VzZWxsc2NoYWZ0IEJvbm4NClVTdC1JZE5yLiBERSA4 MTQ2NDUyNjINCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClZvbjog cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10g SW0gQXVmdHJhZyB2b24gQmFycnkgRGluZ2xlDQpHZXNlbmRldDogU2Ftc3RhZywgMjkuIEp1bmkg MjAxMyAxMjoyNw0KQW46IFdhbmd5YWh1aSAoWWFodWkpDQpDYzogcnRjd2ViQGlldGYub3JnDQpC ZXRyZWZmOiBSZTogW3J0Y3dlYl0gV2ViUlRDIHNlcnZpY2UgYmV0d2VlbiBTUHMNCg0KSSBoYWQg YXNzdW1lZCB0aGF0IGEgRE5TIE5BUFRSIHJlY29yZCBjb3VsZCBiZSB1c2VkIHRvIHByb3ZpZGUg YWxsIHRoZSBhbHRlcm5hdGUgInVzZXIgaWQncyIuIEFtIEkgcmlnaHQ/DQoNCkNoZWVycywNCi9C YXJyeQ0KDQpCYXJyeSBEaW5nbGUNCkZpeGVkIC0gKzYxKDApMy05NzI1LTM5MzcgICAgTW9iIC0g KzYxKDApNDEtOTExLTc1NzgNCkZlbGxvdyBvZiBVbml2ZXJzaXR5IG9mIE1lbGJvdXJuZSwgRWxl Y3RyaWNhbCBhbmQgRWxlY3Ryb25pYyBFbmcuLCBBdXN0cmFsaWENCj4gTGludXggKyBBbmRyb2lk ICsgQXBwbGUgKyBPcGVuIFNvdXJjZSBzb2Z0d2FyZQ0KDQoNCk9uIFNhdCwgSnVuIDI5LCAyMDEz IGF0IDc6MjkgUE0sIFdhbmd5YWh1aSAoWWFodWkpIDx5YWh1aS53YW5nQGh1YXdlaS5jb208bWFp bHRvOnlhaHVpLndhbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB5b3VyIGNvbW1l bnRzLg0KWWVzLCB3ZSBjYW4gaW1wbGVtZW50IHRoZSBmZWRlcmF0aW9uIGJldHdlZW4gU1BzIHRo cm91Z2ggdXNpbmcgdGhlIHNhbWUgc2lnbmFsaW5nIHByb3RvY29sIChlLmcuIFNJUCkgb3IgZGVw bG95aW5nIGEgZ2F0ZXdheS4NCg0KQnV0IHdoYXQgSSBjb25jZXJuIGlzIGhvdyB0byBjb21wYXRp YmxlIHdpdGggdGhlIGV4aXN0aW5nIHZhcmlvdXMgdXNlciBpZCBmcm9tIGRpZmZlcmVudCBTUHMu IEZvciBleGFtcGxlLCBpZiBHb29nbGUgcHJvdmlkZXMgV2ViUlRDIGNsaWVudCwgdGhlbiB0aGUg dXNlcnMgc2hvdWxkIGJlIGFibGUgdG8gbG9naW4gdXNpbmcgdGhlaXIgR21haWwgYWRkcmVzcy4g SW4gdGhlIHNhbWUgd2F5LCBGYWNlYm9vayBzdXBwb3J0IHRoZSB1c2VycyB1c2luZyBGYWNlYm9v a0lkLiBTbyB0aGUgZm9ybWF0IG9mIGlkZW50aWZpY2F0aW9uIG1heSBiZSBudW1iZXIsIHN0cmlu ZyBvciBlbWFpbCBhbmQgc28gb24uDQoNClRoZSBwcm9ibGVtIGlzIGhvdyB0byBoYW5kbGUgYWRk cmVzc2luZyB1c2VycyBvZiBkaWZmZXJlbnQgU1BzLiBTaG91bGQgaXQgYmUgc3RhbmRhcmRpemVk IHRvIGEgdW5pZmllZCBXZWJSVEMgVVJJPw0KDQpZYWh1aQ0KDQrlj5Hku7bkuro6IEhyaXNoaWtl c2ggS3Vsa2FybmkgW21haWx0bzpyaXNoaUB0dXJ0bGV5b2dpLmNvbTxtYWlsdG86cmlzaGlAdHVy dGxleW9naS5jb20+XQ0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0NuaciDI55pelIDE0OjE4DQrmlLbk u7bkuro6IE1vaXNlcyBTaWx2YQ0K5oqE6YCBOiBKaW0gQmFybmV0dDsgV2FuZ3lhaHVpIChZYWh1 aSk7IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0K5Li76aKYOiBSZTog W3J0Y3dlYl0gV2ViUlRDIHNlcnZpY2UgYmV0d2VlbiBTUHMNCg0KU0lQIGlzIGFuIGVzdGFibGlz aGVkIHN0YW5kYXJkIHRvIGludGVyb3BlcmF0ZSBkb21haW5zLiBXZSBhdCBPbmVLbGlrU3RyZWV0 LmNvbSBkZXZlbG9wZWQgYSB2aWRlby9hdWRpbyBicmlkZ2luZyBzZXJ2aWNlIGZvciBXZWJSVEMu IEFsdGhvdWdoIGl0IHVzZXMgSlMvSlNPTiBzaWduYWxpbmcgZm9yIHdlYiBiYXNlZCBjbGllbnRz LiBPdXIgc2VydmVyIGNvdWxkIHZlcnkgd2VsbCBmZWRlcmF0ZSB3aXRoIGFueSBvdGhlciBzZXJ2 aWNlIHVzaW5nIFNJUC4gV2hhdCBkb2VzIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIG9uIGFwcCB0byBh cHAgYmFzaXMgaXMgd2hhdCBraW5kIG9mIGZlZGVyYXRpb24geW91IGFyZSBsb29raW5nIGZvcj8N CkluIGNhc2Ugb2YgYnJpZGdpbmcgc2VydmljZSB3ZSBjb3VsZCBtZXJnZSBjYWxscyBmcm9tIGJv dGggc2VydmVycyBvciByZWRpcmVjdCBhbGwgdGhlIGNhbGxzIHRvIHRoZSBob3N0IHNlcnZpY2Uu DQoNCnJlZ2FyZHMsDQpSaXNoaQ0KRm91bmRlciwgT25lS2xpa1N0cmVldC5jb20NCg0KDQoNCk9u IEZyaSwgSnVuIDI4LCAyMDEzIGF0IDExOjU1IFBNLCBNb2lzZXMgU2lsdmEgPG1vaXNlcy5zaWx2 YUBnbWFpbC5jb208bWFpbHRvOm1vaXNlcy5zaWx2YUBnbWFpbC5jb20+PiB3cm90ZToNCg0KT24g RnJpLCBKdW4gMjgsIDIwMTMgYXQgMTI6MDMgUE0sIEppbSBCYXJuZXR0IDxKaW0uQmFybmV0dEBn ZW5lc3lzbGFiLmNvbTxtYWlsdG86SmltLkJhcm5ldHRAZ2VuZXN5c2xhYi5jb20+PiB3cm90ZToN CkFzIEkgdW5kZXJzdGFuZCBpdCwgaXTigJlzIG5vdCBqdXN0IGEgcHJvYmxlbSBvZiBpZGVudGl0 aWVzLiAgV2ViUlRDIGRvZXMgbm90IGRlZmluZSB0aGUgc2lnbmFsaW5nIHByb3RvY29sLCBidXQg bGVhdmVzIGl0ICB1cCB0byB0aGUgYXBwbGljYXRpb24uICBJZiB0d28gdXNlcnMgZG93bmxvYWQg dGhlaXIgYXBwbGljYXRpb25zL0phdmFTY3JpcHQgZnJvbSB0aGUgc2FtZSBzaXRlLCBpdCB3b27i gJl0IGJlIGEgcHJvYmxlbSwgYmVjYXVzZSB0aGUgc2FtZSBhcHBsaWNhdGlvbiBpcyBoYW5kbGlu ZyBib3RoIGVuZHMgb2YgdGhlIGNhbGwuICBCdXQgaWYgb25lIHVzZXIgaXMgb24gc2l0ZSBBIHdo aWxlIHRoZSBvdGhlciBpcyBvbiBzaXRlIEIsIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IGVp dGhlciBzaXRl4oCZcyBhcHBsaWNhdGlvbiB3aWxsIHVuZGVyc3RhbmQgdGhlIHNpZ25hbGluZyBm cm9tIHRoZSBvdGhlci4NCg0KVW5sZXNzIHdlYnNpdGVzIGFncmVlIHRvIHVzZSBzb21ldGhpbmcg c3RhbmRhcmQgc3VjaCBhcyBTSVAvSmluZ2xlIGZvciBmZWRlcmF0aW9uIChpbnRlciB3ZWJzaXRl L2RvbWFpbiBjb21tdW5pY2F0aW9uKS4NCg0KLQ0KTW95DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJA aWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxt YWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWINCg0KDQo= --_000_AAE428925197FE46A5F94ED6643478FEAC99A4C7C6HE111644EMEA1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTk0MTIiPjwvSEVBRD4NCjxCT0RZPg0KPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDA3MjE0OTE0LTAxMDcyMDEzPjxGT05UIGNvbG9y PSMwMDAwZmYgDQpzaXplPTIgZmFjZT1BcmlhbD5JZiB5b3VyIFdFQlJUQyBzZXJ2aWNlIGFjY2Vw dHMgM3JkIHBhcnR5IGF1dGggZnJvbSBHb29nbGUsIEZCLCANClR3aXR0ZXIsIGEgKmxvdCogb2Yg cGVvcGxlJm5ic3A7Y2FuIHVzZSBpdCBhbmQgeW91IGRvbid0IGhhdmUgdG8gd29ycnkgDQphYm91 dDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz0wMDcyMTQ5MTQtMDEwNzIwMTM+PEZPTlQgY29sb3I9IzAwMDBmZiANCnNpemU9MiBmYWNlPUFy aWFsPmxlZ2FjeSBpbnRlcmNvbm5lY3Rpb24gY29uY2VwdHMgdXNpbmcgU0lQIG9yIFhNUFAuIFRo ZXJlIGlzIG5vIA0KbG9uZ2VyIHRoZSBuZWVkIGZvciBhIHNpbmdsZSwgZ2xvYmFsJm5ic3A7c2ln bmFsbGluZyBwcm90b2NvbCB0aGF0IGNvdmVycyBhbGwgDQpwb3NzaWJsZSB1c2UtY2FzZXMuIFdl IG9ubHkgbmVlZCBhIHdheSB0byBhdXRoZW50aWNhdGUgY2FsbGVycywgYW5kIA0KcGVyaGFwcyZu YnNwO3RoZWlyIFVSTCB0byByZWFjaCB0aGVtIGZvciBhIHJldHVybiBjYWxsLiBCb3RoIGNhbiBi ZSBkb25lIHdpdGggDQozcmQgcGFydHkgYXV0aGVudGljYXRpb24gcHJvdG9jb2xzLiBUb2RheS48 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiBmYWNl PUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj48IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcnRmIGZv cm1hdCAtLT4NCjxQPjxTUEFOIGNsYXNzPTAwNzIxNDkxNC0wMTA3MjAxMz48L1NQQU4+PEZPTlQg ZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+UjxTUEFOIA0KY2xhc3M9MDA3MjE0OTE0LTAxMDcyMDEz PmVnYXJkcyw8L1NQQU4+PC9GT05UPjwvRk9OVD48QlI+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCAN CnNpemU9MiBmYWNlPUFyaWFsPldvbGZnYW5nIEJlY2s8L0ZPTlQ+PC9TUEFOPiA8L1A+PEJSPg0K PFA+PFNQQU4gbGFuZz1lbi1nYj48Rk9OVCBjb2xvcj0jOTk5OTk5IHNpemU9MSBmYWNlPUFyaWFs PkRldXRzY2hlIFRlbGVrb20gDQpUZWNobmlrIEdtYkg8L0ZPTlQ+PC9TUEFOPiA8QlI+PFNQQU4g bGFuZz1lbi1nYj48Rk9OVCBjb2xvcj0jOTk5OTk5IHNpemU9MSANCmZhY2U9QXJpYWw+Rml4ZWQg TW9iaWxlIEVuZ2luZWVyaW5nIERldXRzY2hsYW5kPC9GT05UPjwvU1BBTj4gPEJSPjxTUEFOIA0K bGFuZz1lbi1nYj48Rk9OVCBjb2xvcj0jOTk5OTk5IHNpemU9MSBmYWNlPUFyaWFsPldvbGZnYW5n IEJlY2s8L0ZPTlQ+PC9TUEFOPiANCjxCUj48U1BBTiBsYW5nPWVuLWdiPjxGT05UIGNvbG9yPSM5 OTk5OTkgc2l6ZT0xIGZhY2U9QXJpYWw+SGVpbnJpY2gtSGVydHotU3RyYcOfZSANCjMtNywgNjQy OTUgRGFybXN0YWR0PC9GT05UPjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZW4tZ2I+PEZPTlQgY29s b3I9Izk5OTk5OSANCnNpemU9MSBmYWNlPUFyaWFsPis0OSA2MTUxIDU4MSAyODMyIChUZWwuKTwv Rk9OVD48L1NQQU4+IDxCUj48U1BBTiANCmxhbmc9ZW4tZ2I+PC9TUEFOPjxBIGhyZWY9Imh0dHA6 Ly93d3cudGVsZWtvbS5kZS8iPjxTUEFOIGxhbmc9ZW4tZ2I+PEZPTlQgDQpjb2xvcj0jOTk5OTk5 IHNpemU9MSBmYWNlPUFyaWFsPnd3dy50ZWxla29tLmRlPC9GT05UPjwvU1BBTj48L0E+PFNQQU4g DQpsYW5nPWVuLWdiPjwvU1BBTj48U1BBTiBsYW5nPWRlPjxGT05UIGNvbG9yPSM5OTk5OTkgc2l6 ZT0xIA0KZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PEZPTlQgY29sb3I9I2UyMDA3NCBzaXplPTEg ZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PEZPTlQgDQpjb2xvcj0jOTk5OTk5IHNpemU9MSBmYWNl PUFyaWFsPjwvRk9OVD4mbmJzcDs8Rk9OVCBjb2xvcj0jZTIwMDc0IHNpemU9MSANCmZhY2U9QXJp YWw+IDwvRk9OVD48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1kZT48Rk9OVCBjb2xvcj0jZTIw MDc0IHNpemU9MSBmYWNlPUFyaWFsPkVybGViZW4sIHdhcyANCnZlcmJpbmRldC48L0ZPTlQ+PEZP TlQgY29sb3I9IzgwODAwMCBzaXplPTEgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PEZPTlQgDQpj b2xvcj0jOTc5Nzk3IHNpemU9MSBmYWNlPUFyaWFsPjwvRk9OVD4gPC9TUEFOPjwvUD4NCjxQPjxT UEFOIGxhbmc9ZGU+PEZPTlQgY29sb3I9Izk5OTk5OSBzaXplPTEgZmFjZT1BcmlhbD5EZXV0c2No ZSBUZWxla29tIFRlY2huaWsgDQpHbWJIPC9GT05UPjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZGU+ PEZPTlQgY29sb3I9Izk5OTk5OSBzaXplPTEgDQpmYWNlPUFyaWFsPkF1ZnNpY2h0c3JhdDogRHIu IFRob21hcyBLbm9sbCAoVm9yc2l0emVuZGVyKTwvRk9OVD48L1NQQU4+IDxCUj48U1BBTiANCmxh bmc9ZGU+PEZPTlQgY29sb3I9Izk5OTk5OSBzaXplPTEgZmFjZT1BcmlhbD5HZXNjaMOkZnRzZsO8 aHJ1bmc6IERyLiBCcnVubyANCkphY29iZmV1ZXJib3JuIChWb3JzaXR6ZW5kZXIpLCBBbGJlcnQg TWF0aGVpcywgS2xhdXMgUGVyZW48L0ZPTlQ+PC9TUEFOPiANCjxCUj48U1BBTiBsYW5nPWRlPjxG T05UIGNvbG9yPSM5OTk5OTkgc2l6ZT0xIGZhY2U9QXJpYWw+SGFuZGVsc3JlZ2lzdGVyOiANCkFt dHNnZXJpY2h0IEJvbm4gSFJCIDE0MTkwPC9GT05UPjwvU1BBTj4gPEJSPjxTUEFOIGxhbmc9ZGU+ PEZPTlQgY29sb3I9Izk5OTk5OSANCnNpemU9MSBmYWNlPUFyaWFsPlNpdHogZGVyIEdlc2VsbHNj aGFmdCBCb25uPC9GT05UPjwvU1BBTj4gPEJSPjxTUEFOIA0KbGFuZz1kZT48Rk9OVCBjb2xvcj0j OTk5OTk5IHNpemU9MSBmYWNlPUFyaWFsPlVTdC1JZE5yLiBERSANCjgxNDY0NTI2MjwvRk9OVD48 L1NQQU4+IDwvUD48QlI+PEJSPg0KPERJVj4mbmJzcDs8L0RJVj48QlI+DQo8RElWIGRpcj1sdHIg bGFuZz1kZSBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBhbGlnbj1sZWZ0Pg0KPEhSIHRhYklu ZGV4PS0xPg0KPEZPTlQgc2l6ZT0yIGZhY2U9VGFob21hPjxCPlZvbjo8L0I+IHJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnIA0KW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gPEI+SW0gQXVm dHJhZyB2b24gPC9CPkJhcnJ5IA0KRGluZ2xlPEJSPjxCPkdlc2VuZGV0OjwvQj4gU2Ftc3RhZywg MjkuIEp1bmkgMjAxMyAxMjoyNzxCUj48Qj5Bbjo8L0I+IFdhbmd5YWh1aSANCihZYWh1aSk8QlI+ PEI+Q2M6PC9CPiBydGN3ZWJAaWV0Zi5vcmc8QlI+PEI+QmV0cmVmZjo8L0I+IFJlOiBbcnRjd2Vi XSBXZWJSVEMgDQpzZXJ2aWNlIGJldHdlZW4gU1BzPEJSPjwvRk9OVD48QlI+PC9ESVY+DQo8RElW PjwvRElWPg0KPERJViBkaXI9bHRyPkkgaGFkIGFzc3VtZWQgdGhhdCBhIEROUyBOQVBUUiByZWNv cmQgY291bGQgYmUgdXNlZCB0byBwcm92aWRlIGFsbCANCnRoZSBhbHRlcm5hdGUgInVzZXIgaWQn cyIuIEFtIEkgcmlnaHQ/PEJSPjwvRElWPg0KPERJViBjbGFzcz1nbWFpbF9leHRyYT48QlIgY2xl YXI9YWxsPg0KPERJVj5DaGVlcnMsPEJSPi9CYXJyeTxCUj48QlI+QmFycnkgRGluZ2xlPEJSPkZp eGVkIC0gKzYxKDApMy05NzI1LTM5MzcmbmJzcDsgDQombmJzcDsgTW9iIC0gKzYxKDApNDEtOTEx LTc1NzgmbmJzcDsmbmJzcDsgPEJSPkZlbGxvdyBvZiBVbml2ZXJzaXR5IG9mIA0KTWVsYm91cm5l LCBFbGVjdHJpY2FsIGFuZCBFbGVjdHJvbmljIEVuZy4sIEF1c3RyYWxpYSA8QlI+Jmd0OyBMaW51 eCArIEFuZHJvaWQgKyANCkFwcGxlICsgT3BlbiBTb3VyY2Ugc29mdHdhcmU8L0RJVj48QlI+PEJS Pg0KPERJViBjbGFzcz1nbWFpbF9xdW90ZT5PbiBTYXQsIEp1biAyOSwgMjAxMyBhdCA3OjI5IFBN LCBXYW5neWFodWkgKFlhaHVpKSA8U1BBTiANCmRpcj1sdHI+Jmx0OzxBIGhyZWY9Im1haWx0bzp5 YWh1aS53YW5nQGh1YXdlaS5jb20iIA0KdGFyZ2V0PV9ibGFuaz55YWh1aS53YW5nQGh1YXdlaS5j b208L0E+Jmd0OzwvU1BBTj4gd3JvdGU6PEJSPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVS LUxFRlQ6ICNjY2MgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5H LUxFRlQ6IDFleCIgDQpjbGFzcz1nbWFpbF9xdW90ZT4NCiAgPERJViBsYW5nPVpILUNOIHZsaW5r PSJwdXJwbGUiIGxpbms9ImJsdWUiPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQ QU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6 ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTAuNXB0IiANCiAgbGFuZz1FTi1VUz5UaGFua3MgZm9yIHlv dXIgY29tbWVudHMuPFU+PC9VPjxVPjwvVT48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsg Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTAuNXB0IiANCiAgbGFuZz1FTi1VUz5ZZXMsIHdl IGNhbiBpbXBsZW1lbnQgdGhlIGZlZGVyYXRpb24gYmV0d2VlbiBTUHMgdGhyb3VnaCB1c2luZyB0 aGUgDQogIHNhbWUgc2lnbmFsaW5nIHByb3RvY29sIChlLmcuIFNJUCkgb3IgZGVwbG95aW5nIGEg DQogIGdhdGV3YXkuPFU+PC9VPjxVPjwvVT48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsg Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTAuNXB0IiANCiAgbGFuZz1FTi1VUz48VT48L1U+ PFU+PC9VPjwvU1BBTj4mbmJzcDs8L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3 ZDsgRk9OVC1TSVpFOiAxMC41cHQiIA0KICBsYW5nPUVOLVVTPkJ1dCB3aGF0IEkgY29uY2VybiBp cyBob3cgdG8gY29tcGF0aWJsZSB3aXRoIHRoZSBleGlzdGluZyB2YXJpb3VzIA0KICB1c2VyIGlk IGZyb20gZGlmZmVyZW50IFNQcy4gRm9yIGV4YW1wbGUsIGlmIEdvb2dsZSBwcm92aWRlcyBXZWJS VEMgY2xpZW50LCANCiAgdGhlbiB0aGUgdXNlcnMgc2hvdWxkIGJlIGFibGUgdG8gbG9naW4gdXNp bmcgdGhlaXIgR21haWwgYWRkcmVzcy4gSW4gdGhlIHNhbWUgDQogIHdheSwgRmFjZWJvb2sgc3Vw cG9ydCB0aGUgdXNlcnMgdXNpbmcgRmFjZWJvb2tJZC4gU28gdGhlIGZvcm1hdCBvZiANCiAgaWRl bnRpZmljYXRpb24gbWF5IGJlIG51bWJlciwgc3RyaW5nIG9yIGVtYWlsIGFuZCBzbyANCiAgb24u PFU+PC9VPjxVPjwvVT48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQog IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5 N2Q7IEZPTlQtU0laRTogMTAuNXB0IiANCiAgbGFuZz1FTi1VUz48VT48L1U+PFU+PC9VPjwvU1BB Tj4mbmJzcDs8L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQt RkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpF OiAxMC41cHQiIA0KICBsYW5nPUVOLVVTPlRoZSBwcm9ibGVtIGlzIGhvdyB0byBoYW5kbGUgYWRk cmVzc2luZyB1c2VycyBvZiBkaWZmZXJlbnQgU1BzLiANCiAgU2hvdWxkIGl0IGJlIHN0YW5kYXJk aXplZCB0byBhIHVuaWZpZWQgV2ViUlRDIFVSST88VT48L1U+PFU+PC9VPjwvU1BBTj48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMC41cHQiIA0KICBs YW5nPUVOLVVTPjxVPjwvVT48VT48L1U+PC9TUEFOPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJp Zic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwLjVwdCIgDQogIGxhbmc9RU4tVVM+WWFo dWk8VT48L1U+PFU+PC9VPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiAN CiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFm NDk3ZDsgRk9OVC1TSVpFOiAxMC41cHQiIA0KICBsYW5nPUVOLVVTPjxVPjwvVT48VT48L1U+PC9T UEFOPiZuYnNwOzwvUD4NCiAgPERJViANCiAgc3R5bGU9IkJPUkRFUi1CT1RUT006IG1lZGl1bSBu b25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwY207IFBBRERJ TkctTEVGVDogMGNtOyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0 IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTog5a6L5L2TOyBG T05ULVNJWkU6IDEwcHQiPuWPkeS7tuS6ujxTUEFOIA0KICBsYW5nPUVOLVVTPjo8L1NQQU4+PC9T UEFOPjwvQj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IOWui+S9kzsgRk9OVC1TSVpFOiAxMHB0 IiANCiAgbGFuZz1FTi1VUz4gSHJpc2hpa2VzaCBLdWxrYXJuaSBbbWFpbHRvOjxBIGhyZWY9Im1h aWx0bzpyaXNoaUB0dXJ0bGV5b2dpLmNvbSIgDQogIHRhcmdldD1fYmxhbms+cmlzaGlAdHVydGxl eW9naS5jb208L0E+XSA8QlI+PC9TUEFOPjxCPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6 IOWui+S9kzsgRk9OVC1TSVpFOiAxMHB0Ij7lj5HpgIHml7bpl7Q8U1BBTiANCiAgbGFuZz1FTi1V Uz46PC9TUEFOPjwvU1BBTj48L0I+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiDlrovkvZM7IEZP TlQtU0laRTogMTBwdCIgDQogIGxhbmc9RU4tVVM+IDIwMTM8L1NQQU4+PFNQQU4gc3R5bGU9IkZP TlQtRkFNSUxZOiDlrovkvZM7IEZPTlQtU0laRTogMTBwdCI+5bm0PFNQQU4gDQogIGxhbmc9RU4t VVM+NjwvU1BBTj7mnIg8U1BBTiBsYW5nPUVOLVVTPjI5PC9TUEFOPuaXpTxTUEFOIGxhbmc9RU4t VVM+IA0KICAxNDoxODxCUj48L1NQQU4+PEI+5pS25Lu25Lq6PFNQQU4gbGFuZz1FTi1VUz46PC9T UEFOPjwvQj48U1BBTiBsYW5nPUVOLVVTPiBNb2lzZXMgDQogIFNpbHZhPEJSPjwvU1BBTj48Qj7m ioTpgIE8U1BBTiBsYW5nPUVOLVVTPjo8L1NQQU4+PC9CPjxTUEFOIGxhbmc9RU4tVVM+IEppbSAN CiAgQmFybmV0dDsgV2FuZ3lhaHVpIChZYWh1aSk7IDxBIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciIA0KICB0YXJnZXQ9X2JsYW5rPnJ0Y3dlYkBpZXRmLm9yZzwvQT48QlI+PC9TUEFOPjxC PuS4u+mimDxTUEFOIA0KICBsYW5nPUVOLVVTPjo8L1NQQU4+PC9CPjxTUEFOIGxhbmc9RU4tVVM+ IFJlOiBbcnRjd2ViXSBXZWJSVEMgc2VydmljZSBiZXR3ZWVuIA0KICBTUHM8VT48L1U+PFU+PC9V PjwvU1BBTj48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8RElWIGNsYXNzPWg1Pg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz48VT48L1U+PFU+PC9VPjwvU1BBTj4m bmJzcDs8L1A+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVT PlNJUCBpcyBhbiBlc3RhYmxpc2hlZCBzdGFuZGFyZCB0byANCiAgaW50ZXJvcGVyYXRlIGRvbWFp bnMuIFdlIGF0IE9uZUtsaWtTdHJlZXQuY29tIGRldmVsb3BlZCBhIHZpZGVvL2F1ZGlvIGJyaWRn aW5nIA0KICBzZXJ2aWNlIGZvciBXZWJSVEMuIEFsdGhvdWdoIGl0IHVzZXMgSlMvSlNPTiBzaWdu YWxpbmcgZm9yIHdlYiBiYXNlZCBjbGllbnRzLiANCiAgT3VyIHNlcnZlciBjb3VsZCB2ZXJ5IHdl bGwgZmVkZXJhdGUgd2l0aCBhbnkgb3RoZXIgc2VydmljZSB1c2luZyBTSVAuIFdoYXQgDQogIGRv ZXMgbmVlZCB0byBiZSBkaXNjdXNzZWQgb24gYXBwIHRvIGFwcCBiYXNpcyBpcyB3aGF0IGtpbmQg b2YgZmVkZXJhdGlvbiB5b3UgDQogIGFyZSBsb29raW5nIGZvcj8mbmJzcDs8VT48L1U+PFU+PC9V PjwvU1BBTj48L1A+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVO LVVTPkluIGNhc2Ugb2YgYnJpZGdpbmcgc2VydmljZSB3ZSBjb3VsZCBtZXJnZSANCiAgY2FsbHMg ZnJvbSBib3RoIHNlcnZlcnMgb3IgcmVkaXJlY3QgYWxsIHRoZSBjYWxscyB0byB0aGUgaG9zdCAN CiAgc2VydmljZS48VT48L1U+PFU+PC9VPjwvU1BBTj48L1A+DQogIDxESVY+DQogIDxESVY+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjxVPjwvVT48VT48L1U+PC9TUEFO PiZuYnNwOzwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxh bmc9RU4tVVM+cmVnYXJkcyw8VT48L1U+PFU+PC9VPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPlJpc2hpPFU+PC9VPjxVPjwv VT48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g bGFuZz1FTi1VUz5Gb3VuZGVyLCANCiAgT25lS2xpa1N0cmVldC5jb208VT48L1U+PFU+PC9VPjwv U1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5n PUVOLVVTPjxVPjwvVT48VT48L1U+PC9TUEFOPiZuYnNwOzwvUD48L0RJVj4NCiAgPERJVj4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICBsYW5nPUVOLVVTPjxVPjwvVT48VT48L1U+PC9T UEFOPiZuYnNwOzwvUD48L0RJVj48L0RJVj48L0RJVj48L0RJVj4NCiAgPERJVj4NCiAgPFAgc3R5 bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgbGFuZz1F Ti1VUz48VT48L1U+PFU+PC9VPjwvU1BBTj4mbmJzcDs8L1A+DQogIDxESVY+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPk9uIEZyaSwgSnVuIDI4LCAyMDEzIGF0IDExOjU1 IFBNLCBNb2lzZXMgDQogIFNpbHZhICZsdDs8QSBocmVmPSJtYWlsdG86bW9pc2VzLnNpbHZhQGdt YWlsLmNvbSIgDQogIHRhcmdldD1fYmxhbms+bW9pc2VzLnNpbHZhQGdtYWlsLmNvbTwvQT4mZ3Q7 IHdyb3RlOjxVPjwvVT48VT48L1U+PC9TUEFOPjwvUD4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PFU+PC9VPjxVPjwvVT48L1NQQU4+Jm5ic3A7PC9QPg0K ICA8RElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTi1VUz5P biBGcmksIEp1biAyOCwgMjAxMyBhdCAxMjowMyBQTSwgSmltIA0KICBCYXJuZXR0ICZsdDs8QSBo cmVmPSJtYWlsdG86SmltLkJhcm5ldHRAZ2VuZXN5c2xhYi5jb20iIA0KICB0YXJnZXQ9X2JsYW5r PkppbS5CYXJuZXR0QGdlbmVzeXNsYWIuY29tPC9BPiZndDsgDQogIHdyb3RlOjxVPjwvVT48VT48 L1U+PC9TUEFOPjwvUD4NCiAgPERJVj4NCiAgPEJMT0NLUVVPVEUgDQogIHN0eWxlPSJCT1JERVIt Qk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6ICNjY2NjY2MgMXB0IHNvbGlkOyBQQURE SU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6IDZwdDsgUEFERElORy1SSUdIVDogMGNtOyBN QVJHSU4tTEVGVDogNC44cHQ7IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBNQVJHSU4tUklHSFQ6 IDBjbTsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDBjbSI+DQogICAg PERJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgICBzdHls ZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBG T05ULVNJWkU6IDExcHQiIA0KICAgIGxhbmc9RU4tVVM+QXMgSSB1bmRlcnN0YW5kIGl0LCBpdOKA mXMgbm90IGp1c3QgYSBwcm9ibGVtIG9mIGlkZW50aXRpZXMuJm5ic3A7IA0KICAgIFdlYlJUQyBk b2VzIG5vdCBkZWZpbmUgdGhlIHNpZ25hbGluZyBwcm90b2NvbCwgYnV0IGxlYXZlcyBpdCZuYnNw OyB1cCB0byB0aGUgDQogICAgYXBwbGljYXRpb24uJm5ic3A7IElmIHR3byB1c2VycyBkb3dubG9h ZCB0aGVpciBhcHBsaWNhdGlvbnMvSmF2YVNjcmlwdCBmcm9tIA0KICAgIHRoZSBzYW1lIHNpdGUs IGl0IHdvbuKAmXQgYmUgYSBwcm9ibGVtLCBiZWNhdXNlIHRoZSBzYW1lIGFwcGxpY2F0aW9uIGlz IA0KICAgIGhhbmRsaW5nIGJvdGggZW5kcyBvZiB0aGUgY2FsbC4mbmJzcDsgQnV0IGlmIG9uZSB1 c2VyIGlzIG9uIHNpdGUgQSB3aGlsZSB0aGUgDQogICAgb3RoZXIgaXMgb24gc2l0ZSBCLCB0aGVy ZSBpcyBubyBndWFyYW50ZWUgdGhhdCBlaXRoZXIgc2l0ZeKAmXMgYXBwbGljYXRpb24gDQogICAg d2lsbCB1bmRlcnN0YW5kIHRoZSBzaWduYWxpbmcgZnJvbSB0aGUgb3RoZXIuPC9TUEFOPjxTUEFO IA0KICAgIGxhbmc9RU4tVVM+PFU+PC9VPjxVPjwvVT48L1NQQU4+PC9QPjwvRElWPjwvRElWPjwv QkxPQ0tRVU9URT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KbGFuZz1FTi1VUz48VT48 L1U+PFU+PC9VPjwvU1BBTj4mbmJzcDs8L1A+PC9ESVY+PC9ESVY+DQogIDxESVY+DQogIDxQIGNs YXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPlVubGVzcyB3ZWJzaXRlcyBhZ3JlZSB0byB1 c2Ugc29tZXRoaW5nIA0KICBzdGFuZGFyZCBzdWNoIGFzIFNJUC9KaW5nbGUgZm9yIGZlZGVyYXRp b24gKGludGVyIHdlYnNpdGUvZG9tYWluIA0KICBjb21tdW5pY2F0aW9uKS48QlI+PEJSPi08VT48 L1U+PFU+PC9VPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1h bD48U1BBTiANCiAgbGFuZz1FTi1VUz5Nb3k8VT48L1U+PFU+PC9VPjwvU1BBTj48L1A+PC9ESVY+ PC9ESVY+PC9ESVY+DQogIDxQIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0IiBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gDQogIGxhbmc9RU4tVVM+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPEJSPnJ0Y3dlYiANCiAgbWFpbGluZyBsaXN0PEJSPjxBIGhy ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIA0KICB0YXJnZXQ9X2JsYW5rPnJ0Y3dlYkBpZXRm Lm9yZzwvQT48QlI+PEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViIiANCiAgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYjwvQT48VT48L1U+PFU+PC9VPjwvU1BBTj48L1A+PC9ESVY+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgbGFuZz1FTi1VUz48VT48L1U+PFU+PC9VPjwv U1BBTj4mbmJzcDs8L1A+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PEJSPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPnJ0Y3dlYiANCiAgbWFp bGluZyBsaXN0PEJSPjxBIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRm Lm9yZzwvQT48QlI+PEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViIiANCiAgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYjwvQT48QlI+PEJSPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9E SVY+PC9CT0RZPjwvSFRNTD4NCg== --_000_AAE428925197FE46A5F94ED6643478FEAC99A4C7C6HE111644EMEA1_-- From ted.ietf@gmail.com Mon Jul 1 08:59:16 2013 Return-Path: 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 269F511E8241 for ; Mon, 1 Jul 2013 08:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 xSdiIJiNgfHQ for ; Mon, 1 Jul 2013 08:59:15 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACDB11E8215 for ; Mon, 1 Jul 2013 08:59:15 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so3233263wiv.8 for ; Mon, 01 Jul 2013 08:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=raoZTuhvg12+MmymfQKOXZHMMYqWCTnvkVoGs87cCNo=; b=rviQZUUr+R9CdVaYAmhZXeyJXUHQOv3f+UYooxHeXCpIUBPQj6NSuOw6lPCEMW8Uv7 5R/cff4kiIylVrY7/AyAaungJ2RGgze5vTqfxZX3TjWQd6AvlncCF2p6oc0EB2B9zRwJ 7IJzY9/hPGnk759YtWe49VPLVYijhVYsO+jFcjqY1nNR7ON0fqb3+Bl4++CcX59p5Waw FPymfblQdvvJw5+iWVkGJxwna/2yvfZYiq6UyNje/1Jts2A8eC8JPWl7DIj43IJkxO1g QEDGIXv5Q5bUiieUljrDbsDZTKI9vjsYCx+ApovkvmRVt35MWYPOFu0XU3Z0erN0VvxL opbA== MIME-Version: 1.0 X-Received: by 10.194.119.195 with SMTP id kw3mr20350376wjb.64.1372694354620; Mon, 01 Jul 2013 08:59:14 -0700 (PDT) Received: by 10.227.164.137 with HTTP; Mon, 1 Jul 2013 08:59:14 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> Date: Mon, 1 Jul 2013 08:59:14 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=089e0122894664793804e0754fc6 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 15:59:16 -0000 --089e0122894664793804e0754fc6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 7:28 AM, I=F1aki Baz Castillo wrote: > Stefan, the media/transport info will be sent from browser A to > browser B using the custom format the developer of the website chose, > period. I don't understand why you think that the format of the > media/transport info must be constant/fixed for any website using > WebRTC. Because ultimately the media is sent via transports set up by the browser. If the browser must understand every custom format, the system cannot scale. regards, Ted Hardie --089e0122894664793804e0754fc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 7:28 AM, I=F1aki Baz Castillo <= ibc@aliax.net> wrote:
Stefan, the media/transport info will be sent from browser A to
browser B using the custom format the developer of the website chose,
period. I don't understand why you think that the format of the
media/transport info must be constant/fixed for any website using
WebRTC.

Because ultimately the media is sent via tran= sports set up by the browser.=A0 If the browser must understand every custo= m format, the system cannot scale.=A0

regards,

Ted Hardie
--089e0122894664793804e0754fc6-- From ibc@aliax.net Mon Jul 1 09:06:47 2013 Return-Path: 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 A9C3421F9C88 for ; Mon, 1 Jul 2013 09:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 kxn9v-+lTiur for ; Mon, 1 Jul 2013 09:06:43 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id C330011E82A8 for ; Mon, 1 Jul 2013 09:06:17 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so2171012qab.18 for ; Mon, 01 Jul 2013 09:06:13 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=jP0YsSWzxJi19mcYY3vA6V1kG4kVn1pxXk2CUME8G+Q=; b=LDafrU58IBCmFwt4RD7X0X9mnOa8mjrqkKeR3ZrLosVFZyIj+OlBKcO3Uw39eIbb0K IFX4i3jszHWt/0ufYgrNUtk2DSObLl7cMp/8SeTnS1PKk4GtFVpIWyYxt3HgrViiB31v kfSWyOjFA4pdOA+lFtnyPBMewmv+kBVJDh3ni/TW2WVWEys4v9e+LPyMM4YX3l0u/ANI kdKNjvdJPhFjH5kkh0YExG8HthtffXv5WdWvvW+67pk3HNMSDmKNWTM3pxa0538bWQ4m 1yFnyT9K9oamgAEPE4dEVqwF4G1HlWqsXdswjpIObvCOLlYgwRhkJ2glAOQwyJW9HXJ6 4wpw== X-Received: by 10.224.92.79 with SMTP id q15mr14720964qam.104.1372694772361; Mon, 01 Jul 2013 09:06:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 1 Jul 2013 09:05:52 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 1 Jul 2013 18:05:52 +0200 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmHZNL7o0V1psxFEypqPcnvw1O5Yop5eM1fdQ/s7wzByxM7/jrX8zRwf2/uBHJXCDF8y3XO Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 16:06:47 -0000 2013/7/1 Ted Hardie : > On Mon, Jul 1, 2013 at 7:28 AM, I=C3=B1aki Baz Castillo w= rote: >> >> Stefan, the media/transport info will be sent from browser A to >> browser B using the custom format the developer of the website chose, >> period. I don't understand why you think that the format of the >> media/transport info must be constant/fixed for any website using >> WebRTC. > > > Because ultimately the media is sent via transports set up by the browser= . > If the browser must understand every custom format, the system cannot sca= le. Ted, the media can be *perfectly* sent in-the-wire with any custom format the web developer builts (JSON, XML, plain SDP or whatever). The receiver JS app parses the information (i.e. converts from JSON to an Object), extracts the media/transport fields and pass them to the PeerConnection via API methods. It is really so hard? this is how WWW works (in contrast to how SIP works). If it is possible, please take a look to http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale= -00. Best regards. -- I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Mon Jul 1 10:05:30 2013 Return-Path: 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 3B01311E81A8 for ; Mon, 1 Jul 2013 10:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 XKL4l8RRDpeG for ; Mon, 1 Jul 2013 10:05:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A95BE11E81F7 for ; Mon, 1 Jul 2013 10:05:24 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-41-51d1b6cffe28 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 79.91.05990.FC6B1D15; Mon, 1 Jul 2013 19:05:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Mon, 1 Jul 2013 19:05:19 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model Thread-Index: AQHOcibV+w71mSCXSkiQxLiPakqfXQ== Date: Mon, 1 Jul 2013 17:05:18 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C309759@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvre75bRcDDZo3SlhM32djsfZfO7tF 41w7B2aPcw3v2T12zrrL7rFkyU+mAOYoLpuU1JzMstQifbsErozTPzvYC+7zVWz8H9bA2MTT xcjJISFgIjG96wkThC0mceHeerYuRi4OIYHDjBKrbv9jhXAWMkqsvX4HrIpNIFBi674FbCC2 iIClxI25N5lBbGYBD4lpt5aygtjCAjYSfR8+A9VzANXYSmxrY4Uo15OY83klO4jNIqACZB8F G8Mr4CsxZ2kX1K4LzBJv/78Fm8kIdNH3U2uYIOaLS9x6Mh/qUgGJJXvOM0PYohIvH/9jhbAV JXaebYe6R0/ixtQpbBC2tsSyha+ZIZYJSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsY2XMT M3PSy402MQJj4+CW36o7GO+cEznEKM3BoiTOu1nvTKCQQHpiSWp2ampBalF8UWlOavEhRiYO TqkGxj37qyqf1TYxyf7f/+3QuesaK0MZ9zy/O+3/Phlrm+fKGtuYHcLk/SbvVrQOivT4Hxa0 s3gSW1v3Q5e6yOXt0YuzGzIuab2pufeL6xDbSzmP7c1uYkm95qkGasZy+04x85/6Ht2xeaWT 9y+phucnolfmbLm7/aVDoS1H6JTKd4ks/VImZVnsSizFGYmGWsxFxYkAb7pujFsCAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:05:30 -0000 On 2013-07-01 18:06, I=F1aki Baz Castillo wrote:=0A= > 2013/7/1 Ted Hardie :=0A= >> On Mon, Jul 1, 2013 at 7:28 AM, I=F1aki Baz Castillo wro= te:=0A= >>>=0A= >>> Stefan, the media/transport info will be sent from browser A to=0A= >>> browser B using the custom format the developer of the website chose,= =0A= >>> period. I don't understand why you think that the format of the=0A= >>> media/transport info must be constant/fixed for any website using=0A= >>> WebRTC.=0A= >>=0A= >>=0A= >> Because ultimately the media is sent via transports set up by the browse= r.=0A= >> If the browser must understand every custom format, the system cannot sc= ale.=0A= >=0A= >=0A= > Ted, the media can be *perfectly* sent in-the-wire with any custom=0A= > format the web developer builts (JSON, XML, plain SDP or whatever).=0A= =0A= I had the impression that we had consensus for using (S)RTP for the media.= =0A= =0A= > The receiver JS app parses the information (i.e. converts from JSON to=0A= > an Object), extracts the media/transport fields and pass them to the=0A= > PeerConnection via API methods.=0A= =0A= My point is that when the app passes the fields to the PeerConnection, =0A= it must be specified exactly what those fields mean (so that the RTP =0A= send by one browser can be used by another browser receiving it). And =0A= that requirement is the same regardless of if we use SDP generated and =0A= consumed by the browser to describe it or something else.=0A= =0A= >=0A= > It is really so hard? this is how WWW works (in contrast to how SIP works= ).=0A= >=0A= > If it is possible, please take a look to=0A= > http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationa= le-00.=0A= >=0A= > Best regards.=0A= >=0A= > --=0A= > I=F1aki Baz Castillo=0A= > =0A= >=0A= =0A= From saverio.mascolo@gmail.com Mon Jul 1 10:10:09 2013 Return-Path: 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 643C611E8208 for ; Mon, 1 Jul 2013 10:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 NmXQGIQC5uiD for ; Mon, 1 Jul 2013 10:10:08 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5F52311E8232 for ; Mon, 1 Jul 2013 10:10:08 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so9833655ieb.38 for ; Mon, 01 Jul 2013 10:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hKw+1HgjZmytbOMI1NASpRLo0rjsZ21PBYfqvPMn9KU=; b=Pozt72HWPJ5I0KPT3QeZcQc5zviow5FAtx4OFAGp1f9/CRyQnv4kkuMiJgwYELdoof EmZD6/Glvsoy038xBOeNtEONH414iV5p6Gp0q+5Gif1BrE2mzkKdc1rubRJULcUV+iy5 6PKRNEJtsninCXUyhvIvUDYQcv21m7i2D+Eju+bU6B9a2a1KxRX2NGFo9LR35UpsA7C/ VRCH2GX3nL1R1HnDC8WEDyAVbmCtUv6zav4aA/frRQiclOOcmVovjELoJ83tBR40W7qM 0VFPeGzQ1Ovg3zGlxuLuRCK7d8UTRgQA3xxvPw53Z8uLcKBaQjvSxGl5SsnqywGnguG/ IEPA== X-Received: by 10.50.122.100 with SMTP id lr4mr16563829igb.18.1372698607854; Mon, 01 Jul 2013 10:10:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.138.166 with HTTP; Mon, 1 Jul 2013 10:09:47 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C308D3B@ESESSMB209.ericsson.se> References: <51C96E36.2000907@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B1C308D3B@ESESSMB209.ericsson.se> From: Saverio Mascolo Date: Mon, 1 Jul 2013 19:09:47 +0200 Message-ID: To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: multipart/alternative; boundary=001a11c1f7a4e7aa6a04e0764cad Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:10:09 -0000 --001a11c1f7a4e7aa6a04e0764cad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable an evaluation of how h264 and vp8 are able to match a changing quality would be interesting On Sat, Jun 29, 2013 at 3:17 PM, Stefan H=E5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 6/25/13 12:17 PM, Harald Alvestrand wrote: > > Again - thanks for releasing this openly! > > > > I ran the scripts (with a few tweaks; you run on a system where sh is > > bash, not dash, for instance), and got the same numbers within +/- 0.5% > > (probably some binary version skew); > > I re-run the scripts on another computer with another OS today, and I > get exactly the same results as Bo sent out. I noted however that if the > input clips are not cut at 10s (but used in their entire length) the > results get slightly different, but within +/- 0.5%. Can this be the > reason why you get slightly different numbers? > > > > we may have disagreements on the > > parameters to use, but we agree on the numbers those parameters produce= . > > > > (I have since modified the Google framework to include a script that > > pulls in the sources for the needed binaries and compiles them - if you > > want to make 100% sure people are working from the same sources, you ma= y > > want to rebase to a newer version of the comparision toolkit.) > > > > On 06/22/2013 03:41 PM, Bo Burman wrote: > >> Hi all, > >> > >> We have had a look at Google's comparison between VP8 and H.264 > constrained baseline that was posted on April 3rd ( > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07028.html). This > post contains, as the one mentioned above (and if the attachments make it > to the list), information on the exact tools and options used for encodin= g > and should thus be repeatable by anyone interested. > >> > >> As was already stated by others on this list, one major problem is tha= t > Google's test involves the rate control mechanism. Typically codecs are > measured with rate control turned off, since it acts as a huge noise on t= he > measurement. Instead we propose to compare the codecs using fixed > qp-levels. The qp-level is the quantization parameter that affects the > rate/distortion tradeoff. Comparing using fixed qp-levels is what has bee= n > used when benchmarking HEVC against H.264 in the JCT-VC standardization, > for instance. We are going to select a codec (essentially bit stream > format), not a rate control mechanism: Once the codec is selected you can > choose whatever rate control mechanism you wish. > >> > >> We used Google's excellent framework as the baseline and changed the > parameter settings in order to make it possible to measure using fixed qp= . > We used the same sequences, but limited them to the first 10 seconds sinc= e > they varied from 10 seconds to minutes; this also eased computation time. > >> > >> We used two H.264 encoder implementations: X264, which is an > open-source codec that can operate in everything from real-time to slow, > and JM which is the reference implementation that was used to develop > H.264. JM is very slow but attempts to be very efficient in terms of bits > per quality. The results were as follows: > >> > >> X264 baseline vs VP8: H.264 wins with 1% > >> JM baseline vs VP8: H.264 wins with 4% > >> > >> Running times: > >> X264: 1 hour 3 minutes > >> VP8: 2 hours 0 minutes > >> JM: order of magnitude slower > >> > >> It is interesting to note that the measurements are more stable in the > new test; the variance of the percentages for the sequences is now around > 70, down from around 700 in Google's test of April 3rd. We believe this = is > due to the removal of the rate controller, which acts like noise on the > measurements. > >> > >> We also tried setting H.264 to constrained high (no interlace and no > B-pictures, compared to high). The results were then: > >> > >> X264 constrained high vs VP8: H.264 wins with 25% > >> JM constrained high vs VP8: H.264 wins with 24% > >> > >> We also note that the script that Google provided to calculate the rat= e > differences ("BD-rate") does not give exactly the same numbers as the > JCT-VC-way of calculating BD-rate. The main difference is that the JM sco= re > for constrained high is better (around 29%) if the JCT-VC way of > calculating BD-rate is used. > >> > >> In summary we think that proper testing can conclude that there is no > clear performance advantage to any codec between VP8 and H.264 baseline. > When comparing VP8 against H.264 constrained high on the other hand, it > seems like there is an advantage for H.264 constrained high. > >> > >> The attached file includes the files necessary to reproduce the test. > >> > >> Best Regards, > >> > >> Bo Burman > >> > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c1f7a4e7aa6a04e0764cad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
an evaluation of how h264 and vp8 are able to match a chan= ging quality would be interesting


On Sat, Jun 29, 2013 at 3:17 PM, Stefan H=E5kansson LK = <stefan.lk.hakansson@ericsson.com> wrote:
On 6/25/13 12:17 PM, Haral= d Alvestrand wrote:
> Again - thanks for releasing this openly!
>
> I ran the scripts (with a few tweaks; you run on a system where sh is<= br> > bash, not dash, for instance), and got the same numbers within +/- 0.5= %
> (probably some binary version skew);

I re-run the scripts on another computer with another OS today, and I=
get exactly the same results as Bo sent out. I noted however that if the input clips are not cut at 10s (but used in their entire length) the
results get slightly different, but within +/- 0.5%. Can this be the
reason why you get slightly different numbers?


> we may have disagreements on the
> parameters to use, but we agree on the numbers those parameters produc= e.
>
> (I have since modified the Google framework to include a script that > pulls in the sources for the needed binaries and compiles them - if yo= u
> want to make 100% sure people are working from the same sources, you m= ay
> want to rebase to a newer version of the comparision toolkit.)
>
> On 06/22/2013 03:41 PM, Bo Burman wrote:
>> Hi all,
>>
>> We have had a look at Google's comparison between VP8 and H.26= 4 constrained baseline that was posted on April 3rd (h= ttp://www.ietf.org/mail-archive/web/rtcweb/current/msg07028.html). This= post contains, as the one mentioned above (and if the attachments make it = to the list), information on the exact tools and options used for encoding = and should thus be repeatable by anyone interested.
>>
>> As was already stated by others on this list, one major problem is= that Google's test involves the rate control mechanism. Typically code= cs are measured with rate control turned off, since it acts as a huge noise= on the measurement. Instead we propose to compare the codecs using fixed q= p-levels. The qp-level is the quantization parameter that affects the rate/= distortion tradeoff. Comparing using fixed qp-levels is what has been used = when benchmarking HEVC against H.264 in the JCT-VC standardization, for ins= tance. We are going to select a codec (essentially bit stream format), not = a rate control mechanism: Once the codec is selected you can choose whateve= r rate control mechanism you wish.
>>
>> We used Google's excellent framework as the baseline and chang= ed the parameter settings in order to make it possible to measure using fix= ed qp. We used the same sequences, but limited them to the first 10 seconds= since they varied from 10 seconds to minutes; this also eased computation = time.
>>
>> We used two H.264 encoder implementations: X264, which is an open-= source codec that can operate in everything from real-time to slow, and JM = which is the reference implementation that was used to develop H.264. JM is= very slow but attempts to be very efficient in terms of bits per quality. = The results were as follows:
>>
>> X264 baseline vs VP8: H.264 wins with 1%
>> JM baseline vs VP8: H.264 wins with 4%
>>
>> Running times:
>> X264: 1 hour 3 minutes
>> VP8: 2 hours 0 minutes
>> JM: order of magnitude slower
>>
>> It is interesting to note that the measurements are more stable in= the new test; the variance of the percentages for the sequences is now aro= und 70, down from around 700 in Google's test of April 3rd. =A0We belie= ve this is due to the removal of the rate controller, which acts like noise= on the measurements.
>>
>> We also tried setting H.264 to constrained high (no interlace and = no B-pictures, compared to high). The results were then:
>>
>> X264 constrained high vs VP8: H.264 wins with 25%
>> JM constrained high vs VP8: H.264 wins with 24%
>>
>> We also note that the script that Google provided to calculate the= rate differences ("BD-rate") does not give exactly the same numb= ers as the JCT-VC-way of calculating BD-rate. The main difference is that t= he JM score for constrained high is better (around 29%) if the JCT-VC way o= f calculating BD-rate is used.
>>
>> In summary we think that proper testing can conclude that there is= no clear performance advantage to any codec between VP8 and H.264 baseline= . When comparing VP8 against H.264 constrained high on the other hand, it s= eems like there is an advantage for H.264 constrained high.
>>
>> The attached file includes the files necessary to reproduce the te= st.
>>
>> Best Regards,
>>
>> Bo Burman
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>

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


=A0
--001a11c1f7a4e7aa6a04e0764cad-- From ibc@aliax.net Mon Jul 1 10:10:37 2013 Return-Path: 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 541BF11E8208 for ; Mon, 1 Jul 2013 10:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 q3Dv+goT+81u for ; Mon, 1 Jul 2013 10:10:31 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB6911E8252 for ; Mon, 1 Jul 2013 10:10:31 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id f11so2081785qae.17 for ; Mon, 01 Jul 2013 10:10:30 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=wqOG7TlZSJQmBr7S5hRAYId7E55A/gh/I5ofL9ztADg=; b=oQgLqehh1AbNuEIWmwp9H0wiiIE2+vgDhiKpf54ibGrmyeyWRZIi9vETWgfv0MiZjb K1d1vOimRmBDQJxNPhLB6mXURrHayqH+vZ5L4XI01QYa2aSjoVeiWL8kGpg2+X4HPjS6 We9g6GidlTBKl7Yi2m6PSF3364xjra0B3VsDpJcv1QxVbZwiqb3aV7w9SizJak3aAk1C QZbdFWNIrRGPY/UefEV7t5oi3RhodAHInK+VYXdzsmusorfNtSHWu/HOuV6wh6qzdWIU pJfuoUlE1xRp+F2mR9Zps5Mhb/VhTN3KALwdsTyQYFA3eUHE4HE3CCt+l0iJiaSI6D37 Ksiw== X-Received: by 10.49.117.195 with SMTP id kg3mr32966364qeb.68.1372698630741; Mon, 01 Jul 2013 10:10:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 1 Jul 2013 10:10:10 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C309759@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309759@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 1 Jul 2013 19:10:10 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmFucEBZPxdr+o7q6x6vDoGqWWOITnFo3UQq3DgbAtHqem8XqdO8tcc0XmexrNFo7VZ3dIp Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:10:37 -0000 2013/7/1 Stefan H=C3=A5kansson LK : >> Ted, the media can be *perfectly* sent in-the-wire with any custom >> format the web developer builts (JSON, XML, plain SDP or whatever). > > I had the impression that we had consensus for using (S)RTP for the media= . I meant "SDP". Of course the browser sends RTP. What I mean is that we DO NOT need to play with a SDP blob to transmit media/transport info between browsers and between JS and WebRTC API. >> The receiver JS app parses the information (i.e. converts from JSON to >> an Object), extracts the media/transport fields and pass them to the >> PeerConnection via API methods. > > My point is that when the app passes the fields to the PeerConnection, > it must be specified exactly what those fields mean (so that the RTP > send by one browser can be used by another browser receiving it). And > that requirement is the same regardless of if we use SDP generated and > consumed by the browser to describe it or something else. Sure. The point is that we don't need (and don't want) SDP since it becomes a barrier for innovation. All the details in the draft: http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationa= le-00. Best regards. -- I=C3=B1aki Baz Castillo From ted.ietf@gmail.com Mon Jul 1 10:14:00 2013 Return-Path: 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 27D0421F99A6 for ; Mon, 1 Jul 2013 10:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 L3cf8refDA7c for ; Mon, 1 Jul 2013 10:13:59 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8363A21F9F38 for ; Mon, 1 Jul 2013 10:13:53 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so3310269wib.12 for ; Mon, 01 Jul 2013 10:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nBAuyGG8ogv4rATreRqp10nYfQSJpMGEw35EoCcxg/M=; b=HJ0NLGQpEOFt8Hw2Wm1u4HkApkmVhwkVK4YWtlqd/wyaASM4cj8T7N69ov7bnxAsQT /S2r0N/DeDdL28V0Ego0JTdInUbZcNBbnKYNTMipAprcvta9c8bhWGq9DdUr6A66SUA4 GAflnWQCNA1rbgeIKl226hECtSjSHi2bJylhJm/QXHvGqL0+IPz6E74z8KzvcP8SS5oT LAkEwrmFTD7yF7SYGRPyzEb6k2Q8mw7xwIDXgIcA3ZevTw0rMkJOHZn1aWoid9pN6Nv5 nIZaYhX16mwLo6ZIuq+xajmflm+Z1tCx6/D3NDmuNWtWRIfCl3IfVtispDkpvU2JFwJA zl5Q== MIME-Version: 1.0 X-Received: by 10.180.108.129 with SMTP id hk1mr12723635wib.56.1372698832232; Mon, 01 Jul 2013 10:13:52 -0700 (PDT) Received: by 10.227.164.137 with HTTP; Mon, 1 Jul 2013 10:13:52 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> Date: Mon, 1 Jul 2013 10:13:52 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8f3bb04f47672d04e0765aa8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:14:00 -0000 --e89a8f3bb04f47672d04e0765aa8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 9:05 AM, I=F1aki Baz Castillo wrote: > 2013/7/1 Ted Hardie : > > On Mon, Jul 1, 2013 at 7:28 AM, I=F1aki Baz Castillo > wrote: > >> > >> Stefan, the media/transport info will be sent from browser A to > >> browser B using the custom format the developer of the website chose, > >> period. I don't understand why you think that the format of the > >> media/transport info must be constant/fixed for any website using > >> WebRTC. > > > > > > Because ultimately the media is sent via transports set up by the > browser. > > If the browser must understand every custom format, the system cannot > scale. > > > Ted, the media can be *perfectly* sent in-the-wire with any custom > format the web developer builts (JSON, XML, plain SDP or whatever). > I'm sorry, I think I must misunderstand you. You are planning to take media from a source and encode it using json, xml, or SDP and send that over the wire? Or you mean the media *signalling* can use json, xml, or SDP and go over the wire? > The receiver JS app parses the information (i.e. converts from JSON to > an Object), extracts the media/transport fields and pass them to the > PeerConnection via API methods. > It is really so hard? this is how WWW works (in contrast to how SIP works). > > As has been repeatedly mentioned, you have a peer communication here that has to be implemented by the browser. That means the downloaded javascript application must tell a browser what transports it needs so that it can create the appropriate connections. If it is using RTP/UDP, it ends up needing to tell the browser what enough detail to construct the RTP/UPD streams. What payload format, for example, is needed. As I said before, that means that having no standard format across the API between the JS application and the browser has very poor scaling characteristics. You might replace SDP as the interface between them, but not specifying anything there doesn't seem to work, at least in my personal opinion. regards, Ted Hardie If it is possible, please take a look to > > http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationa= le-00 > . > > Best regards. > > -- > I=F1aki Baz Castillo > > --e89a8f3bb04f47672d04e0765aa8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 9:05 AM, I=F1aki Baz Castillo <= ibc@aliax.net> wrote:
2013/7/1 Ted Hardie <ted.ietf@gmai= l.com>:
> On Mon, Jul 1, 2013 at 7:28 AM, I=F1aki Baz Cas= tillo <ibc@aliax.net> wrote:
>>
>> Stefan, the media/transport info will be sent from browser A to >> browser B using the custom format the developer of the website cho= se,
>> period. I don't understand why you think that the format of th= e
>> media/transport info must be constant/fixed for any website using<= br> >> WebRTC.
>
>
> Because ultimately the media is sent via transports set up by the brow= ser.
> If the browser must understand every custom format, the system cannot = scale.


Ted, the media can be *perfectly* sent in-the-wire with any cus= tom
format the web developer builts (JSON, XML, plain SDP or whatever).

I'm sorry, I think I must misunderstand you.=A0 You a= re planning to take media from a source=A0 and encode it using json, xml, o= r SDP and send that over the wire?=A0 Or you mean the media *signalling* ca= n use json, xml, or SDP and go over the wire?
=A0
The receiver JS app parses the information (i.e. converts from JSON to
an Object), extracts the media/transport fields and pass them to the
PeerConnection via API methods.
=A0
It is really so hard? this is how WWW works (in contrast to how SIP works).=


As has been repeatedly mentioned, you have a peer= communication here that has to be implemented by the browser.=A0 That mean= s the downloaded javascript application must tell a browser what transports= it needs so that it can create the appropriate connections.=A0 If it is us= ing RTP/UDP, it ends up needing to tell the browser what enough detail to c= onstruct the RTP/UPD streams.=A0 What payload format, for example, is neede= d.=A0 As I said before, that means that having no standard format across th= e API between the JS application and the browser has very poor scaling char= acteristics.=A0 You might replace SDP as the interface between them, but no= t specifying anything there doesn't seem to work, at least in my person= al opinion.

regards,

Ted Hardie


If it is possible, please take a look to
http://tools.ietf.org/html/draft-raymond-= rtcweb-webrtc-js-obj-api-rationale-00.

Best regards.

--
I=F1aki Baz Castillo
<ibc@aliax.net>

--e89a8f3bb04f47672d04e0765aa8-- From ibc@aliax.net Mon Jul 1 10:22:49 2013 Return-Path: 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 C75B611E81D5 for ; Mon, 1 Jul 2013 10:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 cckAI+pYuo+W for ; Mon, 1 Jul 2013 10:22:45 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8F24D11E81B0 for ; Mon, 1 Jul 2013 10:22:45 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so2233555qab.1 for ; Mon, 01 Jul 2013 10:22:45 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=B/1ySWpRa+m0kH2oh2UXcmM9HGNKhf1pBe7wBZ4v8rA=; b=IQdhkzNCsFK4cBRCCeypAin2833H8paixcXeEFPq2eiNKUtzvulg2Zik4A8erjEoh+ yF33DBZKo8AYtiFbVC7YsCS3QejMZeb70U5UJPhin7DWNxGfcWqt3PwfLX/gLnIAnWl9 JO/cm3JN0gchySU3MIr6gQIjPstt478NGEIl8dciSTPcvKJZuQ2EqukN1fxb64Lfc49V //cBrFbFXtc6Y7E0OiduEgAciHoIi6oKjZCUDXOERe7iAgFZRl4Zt1+NjFp2DT873qlm XOzo+uag87Z//mZ2VQReZ0+4BHZ85Xz2kXQweFk2iBATRP9WGQm2pqoVLOCR3rgSRyYO WbIA== X-Received: by 10.229.197.71 with SMTP id ej7mr7874232qcb.27.1372699364907; Mon, 01 Jul 2013 10:22:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 1 Jul 2013 10:22:24 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 1 Jul 2013 19:22:24 +0200 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQne5+voTR/3kBlj49MT3EYXks0m66EyDokrq8TnS5e30lvKIn70y3x3gPK0Qs0jAPx6o0AD Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:22:50 -0000 2013/7/1 Ted Hardie : >> Ted, the media can be *perfectly* sent in-the-wire with any custom >> format the web developer builts (JSON, XML, plain SDP or whatever). > > > I'm sorry, I think I must misunderstand you. You are planning to take me= dia > from a source and encode it using json, xml, or SDP and send that over t= he > wire? Or you mean the media *signalling* can use json, xml, or SDP and g= o > over the wire? Of course, I mean "the media signaling". But that is not just about "in-the-wire". Current WebRTC specs mandate that the information unit exchanged between the JS app and the WebRTC stack must be a SDP blob. What I mean is: - The JS app uses the WebRTC API to retrieve a JS Object (or Objects) with transport and media info. - The JS app serializes such a information in any custom way defined by the website developer (this can be a JSON body, XML, SDP! or whatever). - The JS app sends the information to the remote peer. - The JS app of the remote peer decodes the information (since it is a JS app designed by the same domain/website) and extracts all the transport/media fields. - The JS app of the remote peer creates a local PC and makes calls to API methods of PC for passing those transport/media fields. - ...and remove O/A mandate. But honestly, all of this is really well described and exposed in the draft= : http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale= -00 >> The receiver JS app parses the information (i.e. converts from JSON to >> an Object), extracts the media/transport fields and pass them to the >> PeerConnection via API methods. >> >> >> It is really so hard? this is how WWW works (in contrast to how SIP >> works). >> > > As has been repeatedly mentioned, you have a peer communication here that > has to be implemented by the browser. That means the downloaded javascri= pt > application must tell a browser what transports it needs so that it can > create the appropriate connections. If it is using RTP/UDP, it ends up > needing to tell the browser what enough detail to construct the RTP/UPD > streams. What payload format, for example, is needed. As I said before, > that means that having no standard format across the API between the JS > application and the browser has very poor scaling characteristics. You > might replace SDP as the interface between them, but not specifying anyth= ing > there doesn't seem to work, at least in my personal opinion. I invite you to read the draft which describes how your concerns can be perfectly accomplished without mandating SDP or any other format: http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale= -00 Best regards. -- I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Mon Jul 1 10:33:43 2013 Return-Path: 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 0F76621F99D3 for ; Mon, 1 Jul 2013 10:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.064 X-Spam-Level: X-Spam-Status: No, score=-4.064 tagged_above=-999 required=5 tests=[AWL=-1.765, BAYES_00=-2.599, 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 7KNHj81BZL9s for ; Mon, 1 Jul 2013 10:33:38 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBB111E80D7 for ; Mon, 1 Jul 2013 10:33:37 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-68-51d1bd6de52b Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 3E.26.11907.D6DB1D15; Mon, 1 Jul 2013 19:33:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Mon, 1 Jul 2013 19:33:33 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model Thread-Index: AQHOcibV+w71mSCXSkiQxLiPakqfXQ== Date: Mon, 1 Jul 2013 17:33:33 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvrW7u3ouBBi1nLCym77OxWPuvnd2i ca6dA7PHuYb37B47Z91l91iy5CdTAHMUl01Kak5mWWqRvl0CV0bn9bSCZ7IVh4/9YW5gbJfo YuTkkBAwkejomMgCYYtJXLi3nq2LkYtDSOAoo8Te3oWMEM5CRoklPzazg1SxCQRKbN23gA3E FhGwlLgx9yYziM0s4CEx7dZSVhBbWMBGou/DZ6YuRg6gGluJbW2sEOV6EnM+rwQbwyKgIrFs 7wd2kBJeAV+Jtgu5EKvusUi8ndANNpIR6KDvp9YwQYwXl7j1ZD4TxKECEkv2nGeGsEUlXj7+ xwphK0rsPNsOdY6exI2pU9ggbG2JZQtfg8V5BQQlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaW VYwcxanFSbnpRgabGIGxcXDLb4sdjJf/2hxilOZgURLn3aJ3JlBIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDY0Fu1jn5jh3X7uQtvnXw9/l7l/8u5+OZvbFwhd/OUhazHULLPqld2bbANHxS gqlq7ZOSqOXCvC/LvjXrqr6wuB5XOk/6RNCm+tuK3NEzPmSJLXtz0ej2wbYMrQUOPW0TpVbw nlEzfnOSR3rhwrOqH0tSdLv1XThfLCms+S16bdP8Qzn29/es81diKc5INNRiLipOBAA+b+Nm WwIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:33:43 -0000 On 2013-07-01 19:22, I=F1aki Baz Castillo wrote:=0A= > 2013/7/1 Ted Hardie :=0A= >>> Ted, the media can be *perfectly* sent in-the-wire with any custom=0A= >>> format the web developer builts (JSON, XML, plain SDP or whatever).=0A= >>=0A= >>=0A= >> I'm sorry, I think I must misunderstand you. You are planning to take m= edia=0A= >> from a source and encode it using json, xml, or SDP and send that over = the=0A= >> wire? Or you mean the media *signalling* can use json, xml, or SDP and = go=0A= >> over the wire?=0A= >=0A= > Of course, I mean "the media signaling". But that is not just about=0A= > "in-the-wire". Current WebRTC specs mandate that the information unit=0A= > exchanged between the JS app and the WebRTC stack must be a SDP blob.=0A= >=0A= > What I mean is:=0A= >=0A= > - The JS app uses the WebRTC API to retrieve a JS Object (or Objects)=0A= > with transport and media info.=0A= >=0A= > - The JS app serializes such a information in any custom way defined=0A= > by the website developer (this can be a JSON body, XML, SDP! or=0A= > whatever).=0A= >=0A= > - The JS app sends the information to the remote peer.=0A= >=0A= > - The JS app of the remote peer decodes the information (since it is a=0A= > JS app designed by the same domain/website) and extracts all the=0A= > transport/media fields.=0A= >=0A= > - The JS app of the remote peer creates a local PC and makes calls to=0A= > API methods of PC for passing those transport/media fields.=0A= >=0A= > - ...and remove O/A mandate.=0A= =0A= What if first browser generated a JS Object that said (for this example =0A= we assume one single audio track) it preferred to send audio using =0A= Opus2.0 but could also do Opus and G.711. If the second browser (which =0A= has not yet been upgraded) could only decode Opus and G.711, would it =0A= not have to tell the first browser about this?=0A= =0A= Are you perhaps assuming a capability exchange of some sort before any =0A= media can be set up?=0A= =0A= >=0A= > But honestly, all of this is really well described and exposed in the dra= ft:=0A= >=0A= > http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationa= le-00=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >>> The receiver JS app parses the information (i.e. converts from JSON to= =0A= >>> an Object), extracts the media/transport fields and pass them to the=0A= >>> PeerConnection via API methods.=0A= >>>=0A= >>>=0A= >>> It is really so hard? this is how WWW works (in contrast to how SIP=0A= >>> works).=0A= >>>=0A= >>=0A= >> As has been repeatedly mentioned, you have a peer communication here tha= t=0A= >> has to be implemented by the browser. That means the downloaded javascr= ipt=0A= >> application must tell a browser what transports it needs so that it can= =0A= >> create the appropriate connections. If it is using RTP/UDP, it ends up= =0A= >> needing to tell the browser what enough detail to construct the RTP/UPD= =0A= >> streams. What payload format, for example, is needed. As I said before= ,=0A= >> that means that having no standard format across the API between the JS= =0A= >> application and the browser has very poor scaling characteristics. You= =0A= >> might replace SDP as the interface between them, but not specifying anyt= hing=0A= >> there doesn't seem to work, at least in my personal opinion.=0A= >=0A= > I invite you to read the draft which describes how your concerns can=0A= > be perfectly accomplished without mandating SDP or any other format:=0A= >=0A= > http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationa= le-00=0A= >=0A= >=0A= >=0A= > Best regards.=0A= >=0A= >=0A= > --=0A= > I=F1aki Baz Castillo=0A= > =0A= >=0A= =0A= From ted.ietf@gmail.com Mon Jul 1 11:17:51 2013 Return-Path: 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 8094111E81A1 for ; Mon, 1 Jul 2013 11:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 LngWlLYfVGtb for ; Mon, 1 Jul 2013 11:17:50 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4A32111E81EB for ; Mon, 1 Jul 2013 11:17:50 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so3378674wid.4 for ; Mon, 01 Jul 2013 11:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pD4rfFReN48WEajFo4Q8kXvS36hEhjcff3HmexGMOXA=; b=wQz2dFdZ3QlGDshUDO8lUUyQrF21VxODuVw04gmY7DmqmFIzr42bi3d8SKjnBvvLp0 jpdL1weYT2iKJA2LnCBGcPoAL2H4W8ylkOAP2ujAO8riTmzPcNPpFia+7iO5ZEodh1fC coBuwiq981DYTOfcFPDCmmeG4S7ZSknUC9pMnHcRxI6kigIM/NCZQLKaNC4qQ/PNsYyE i3HEvFz8ISZS8grgtfTWtcAkf9TWw1j2ZJwOUpBKm17wjKnNS+QYcLGmV3SNvck/G7I7 trcsbvikNc/rsscTW7nBSo9UFTadJIq9p5IUtNdmsU9xUZYyG9ASQoGhlZsqnzWyGVKC r1PQ== MIME-Version: 1.0 X-Received: by 10.180.108.129 with SMTP id hk1mr12895337wib.56.1372702669387; Mon, 01 Jul 2013 11:17:49 -0700 (PDT) Received: by 10.227.164.137 with HTTP; Mon, 1 Jul 2013 11:17:49 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> Date: Mon, 1 Jul 2013 11:17:49 -0700 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8f3bb04ffdbdaf04e0773ee9 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 18:17:51 -0000 --e89a8f3bb04ffdbdaf04e0773ee9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 10:22 AM, I=F1aki Baz Castillo wrote= : Preface: I have read the document you refer to, and I find it personally a lot less clear than you do. While I would welcome specific pointers when I ask questions, more elucidation is needed for me. Thanks for understanding= . More questions in-line. > Of course, I mean "the media signaling". But that is not just about > "in-the-wire". Current WebRTC specs mandate that the information unit > exchanged between the JS app and the WebRTC stack must be a SDP blob. > > What I mean is: > > - The JS app uses the WebRTC API to retrieve a JS Object (or Objects) > with transport and media info. > > Retrieve from where? Does the browser generate these at the direction of the JS application, or do you believe it generates them when media sources are connected. How are data sources created? > - The JS app serializes such a information in any custom way defined > by the website developer (this can be a JSON body, XML, SDP! or > whatever). > > - The JS app sends the information to the remote peer. > > - The JS app of the remote peer decodes the information (since it is a > JS app designed by the same domain/website) and extracts all the > transport/media fields. > > - The JS app of the remote peer creates a local PC and makes calls to > API methods of PC for passing those transport/media fields. > > - ...and remove O/A mandate. > > But honestly, all of this is really well described and exposed in the > draft: > > > http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationa= le-00 > > > > None of the above appears to touch on the API which uses SDP in the current design; that's between the JS and the browser. > > > >> The receiver JS app parses the information (i.e. converts from JSON to > >> an Object), extracts the media/transport fields and pass them to the > >> PeerConnection via API methods. > >> > >> > >> It is really so hard? this is how WWW works (in contrast to how SIP > >> works). > >> > > > > As has been repeatedly mentioned, you have a peer communication here th= at > > has to be implemented by the browser. That means the downloaded > javascript > > application must tell a browser what transports it needs so that it can > > create the appropriate connections. If it is using RTP/UDP, it ends up > > needing to tell the browser what enough detail to construct the RTP/UPD > > streams. What payload format, for example, is needed. As I said befor= e, > > that means that having no standard format across the API between the JS > > application and the browser has very poor scaling characteristics. You > > might replace SDP as the interface between them, but not specifying > anything > > there doesn't seem to work, at least in my personal opinion. > > I invite you to read the draft which describes how your concerns can > be perfectly accomplished without mandating SDP or any other format: > > > http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationa= le-00 > > Honestly, I have read it and I don't see how you avoid mandating some standard interface between the JS and browser. That needn't be SDP, but if it is causing the two sides to negotiate candidate transports and emit RTP, it's going to be hard going to avoid it being SDPNG. Ted > > > Best regards. > > > -- > I=F1aki Baz Castillo > > --e89a8f3bb04ffdbdaf04e0773ee9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 10:22 AM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:

Preface:=A0 I have read= the document you refer to, and I find it personally a lot less clear than = you do.=A0 While I would welcome specific pointers when I ask questions, mo= re elucidation is needed for me.=A0 Thanks for understanding.

More questions in-line.
=A0
= Of course, I mean "the media signaling". But that is not just abo= ut
"in-the-wire". Current WebRTC specs mandate that the information = unit
exchanged between the JS app and the WebRTC stack must be a SDP blob.

What I mean is:

- The JS app uses the WebRTC API to retrieve a JS Object (or Objects)
with transport and media info.


Retrieve from where?=A0 Does the browser generate= these at the direction of the JS application,
or do you believe it gene= rates them when media sources are connected.=A0 How are data sources
cre= ated?
=A0
- The JS app serializes such a information in any custom way defined
by the website developer (this can be a JSON body, XML, SDP! or
whatever).

- The JS app sends the information to the remote peer.

- The JS app of the remote peer decodes the information (since it is a
JS app designed by the same domain/website) and extracts all the
transport/media fields.

- The JS app of the remote peer creates a local PC and makes calls to
API methods of PC for passing those transport/media fields.

- ...and remove O/A mandate.

But honestly, all of this is really well described and exposed in the draft= :

http://tools.ietf.org/html/draft-raymond-= rtcweb-webrtc-js-obj-api-rationale-00




None of the above appears to touch on the A= PI which uses SDP in the current design; that's between the JS and the = browser.


>> The receiver JS app parses the information (i.e. converts from JSO= N to
>> an Object), extracts the media/transport fields and pass them to t= he
>> PeerConnection via API methods.
>>
>>
>> It is really so hard? this is how WWW works (in contrast to how SI= P
>> works).
>>
>
> As has been repeatedly mentioned, you have a peer communication here t= hat
> has to be implemented by the browser. =A0That means the downloaded jav= ascript
> application must tell a browser what transports it needs so that it ca= n
> create the appropriate connections. =A0If it is using RTP/UDP, it ends= up
> needing to tell the browser what enough detail to construct the RTP/UP= D
> streams. =A0What payload format, for example, is needed. =A0As I said = before,
> that means that having no standard format across the API between the J= S
> application and the browser has very poor scaling characteristics. =A0= You
> might replace SDP as the interface between them, but not specifying an= ything
> there doesn't seem to work, at least in my personal opinion.

I invite you to read the draft which describes how your concerns can<= br> be perfectly accomplished without mandating SDP or any other format:

http://tools.ietf.org/html/draft-raymond-= rtcweb-webrtc-js-obj-api-rationale-00

<= br>Honestly, I have read it and I don't see how you avoid mandating som= e standard
interface between the JS and browser.=A0 That needn't be = SDP, but if it is causing the
two sides to negotiate candidate transports and emit RTP, it's going to= be hard going
to avoid it being SDPNG.

Ted
=A0


Best regards.


--
I=F1aki Baz Castillo
<ibc@aliax.net>

--e89a8f3bb04ffdbdaf04e0773ee9-- From roman@telurix.com Mon Jul 1 11:24:39 2013 Return-Path: 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 DDAB211E81EB for ; Mon, 1 Jul 2013 11:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 sqdiHgi+2uhM for ; Mon, 1 Jul 2013 11:24:31 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2C54811E81DC for ; Mon, 1 Jul 2013 11:24:27 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so3990877wgh.0 for ; Mon, 01 Jul 2013 11:24:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=wP6YPL4xajq+J3wUZugO1Zqbk+lAdL2rP2pbhLM5ZbE=; b=Ld/8TZ+oy5nut8o4BbTV9aIOa2eqt4oLDB7AJLJiDcKvUKcfq2v4uSbKgVpIpb0gT8 NsQPwb5Q7KnmbvxfxqdP+eoMr8bjwhC1pNyGPQMr0voFxYEcqm3QtnJKG0y4dw7pVIH0 8FQ2EWYdGLRZkQ3JzROzWru7xXnKRBc8KAZ7bC+8njJfwfVmRxbHyAnuyswqxJzy6MOM J/1iVIb495EHcHAULgBwl34tADTFfG/FM0dNHmRQ7snWEaQzeIt0pFdNQeWB5Aanjdxj YGxsyi6PomRRBzURUnNMD/RvWflc/Q29k+r+sgYOki0BdhFDlGsH90yfQQtK2lqB5d2b Td1Q== X-Received: by 10.194.11.72 with SMTP id o8mr21420471wjb.0.1372703067221; Mon, 01 Jul 2013 11:24:27 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [2a00:1450:400c:c00::231]) by mx.google.com with ESMTPSA id h8sm18047354wie.1.2013.07.01.11.24.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 11:24:26 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so3949005wgh.28 for ; Mon, 01 Jul 2013 11:24:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.228 with SMTP id kx4mr20637954wjb.33.1372703065031; Mon, 01 Jul 2013 11:24:25 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Mon, 1 Jul 2013 11:24:24 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> Date: Mon, 1 Jul 2013 14:24:24 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: multipart/alternative; boundary=089e012292e292ca2204e0775632 X-Gm-Message-State: ALoCoQmGBkz27rKYsvoPLXTx3YSM5K0fL9mANjDUbqiecVjhSoIa1W2zeNQZE4twkn5J+1QhWW1S Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 18:24:39 -0000 --089e012292e292ca2204e0775632 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 1:33 PM, Stefan H=E5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > What if first browser generated a JS Object that said (for this example > we assume one single audio track) it preferred to send audio using > Opus2.0 but could also do Opus and G.711. If the second browser (which > has not yet been upgraded) could only decode Opus and G.711, would it > not have to tell the first browser about this? > > Are you perhaps assuming a capability exchange of some sort before any > media can be set up? > > Any API that we propose would include methods to expose browser capabilities (ie list of available codecs, with default payload type, payload name, clock rate, number of channels, and preferred codec parameters). Generation of SDP c line, rtpmap, and fmtp lines from this would be trivial, as well as generation of other media descriptions for XMPP or other negotiation protocols. In other words, we are not removing the need for negotiation. All we want is to unbundle it from single offer/answer exchange with single string blob into separate methods where transport negotiation (ie DTLS, SRTP, and ICE candidates), mapping transport to streams (ie any sort of bundle related mapping remote address, SSRC, payload or others), and media encoding/decoding (ie send and receive codecs, codec parameters, payload times, etc) are all negotiated separately and independently. This is what is happening with the API anyway with trickle ICE and no-plan proposal adding ability to update transport and media parameters once the initial connection is established. All we want is to extend the same logic to the initial connection establishment, _____________ Roman Shpount --089e012292e292ca2204e0775632 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 1, 2013 at 1:33 PM, Stefan H=E5kanss= on LK <stefan.lk.hakansson@ericsson.com> wrot= e:
What if first browser generated a JS Object that said (fo= r this example
we assume one single audio track) it preferred to send audio using
Opus2.0 but could also do Opus and G.711. If the second browser (which
has not yet been upgraded) could only decode Opus and G.711, would it
not have to tell the first browser about this?

Are you perhaps assuming a capability exchange of some sort before any
media can be set up?

<= br>
Any API that we propose would include methods to expose brows= er capabilities (ie list of available codecs, with default payload type, pa= yload name, clock rate, number of channels, and preferred codec parameters)= . Generation of SDP c line, rtpmap, and fmtp lines from this would be trivi= al, as well as generation of other media descriptions for XMPP or other neg= otiation protocols.

In other words, we are not removing the need for negoti= ation. All we want is to unbundle it from single offer/answer exchange with= single string blob into separate methods where transport negotiation (ie D= TLS, SRTP, and ICE candidates), mapping transport to streams (ie any sort o= f bundle related mapping remote address, SSRC, payload or others), and medi= a encoding/decoding (ie send and receive codecs, codec parameters, payload = times, etc) are all negotiated separately and independently. This is what i= s happening with the API anyway with trickle ICE and no-plan proposal addin= g ability to update transport and media parameters once the initial connect= ion is established. All we want is to extend the same logic to the initial = connection establishment,=A0
_____________
Roman Shpount
=A0
--089e012292e292ca2204e0775632-- From martin.thomson@gmail.com Mon Jul 1 11:57:54 2013 Return-Path: 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 1928F11E8228 for ; Mon, 1 Jul 2013 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 CWpge00ZTOwb for ; Mon, 1 Jul 2013 11:57:53 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA1811E8234 for ; Mon, 1 Jul 2013 11:57:53 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so4044377wgh.27 for ; Mon, 01 Jul 2013 11:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=IJ5yFBuoG1pOtCR/FO3IjexT6f5gDw+clU76bHmbVKI=; b=vEM9I5z+TY2WT5LWFTc4JxoL3SF1gNSDdPLaKi/95lu0LXkGwbzrUneq7ghF58ylCp sQuFF16Rlqcx+9frc0b7VpWBWJTf55DJpL/DvvY2MG1uSWjvoTAS8HTB2A7BNvw+M95F cFGdjhPfY1DFPXLq0N61BGOdN/QoD/VYPBE0bkPhdXqEPBmsTMyjtoVmHWfkLKCFKJKn JOp1TNNM6mRQBS/TfFrYQaIC1nwnsBdZ2mJpd9ZIGYhdJlv4LEr/yiIrCT48WtHRc5sT cIddzZBm0Rhrns7Ojia8wrZj284XrBwD93Aiu7oGkrr/UdXJtned4A0O3tA8QE2kCin6 qY/Q== MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr12923764wic.65.1372705072371; Mon, 01 Jul 2013 11:57:52 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 1 Jul 2013 11:57:52 -0700 (PDT) Date: Mon, 1 Jul 2013 11:57:52 -0700 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: [rtcweb] New language (was: ... WebRTC JS Object API Model) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 18:57:54 -0000 On 1 July 2013 11:17, Ted Hardie wrote: > Honestly, I have read it and I don't see how you avoid mandating some > standard > interface between the JS and browser. That needn't be SDP, but if it is > causing the > two sides to negotiate candidate transports and emit RTP, it's going to be > hard going > to avoid it being SDPNG. This is an important argument, but it's only correct up to a point. And that is misleading. SDP does a lot of things that an API can do in far simpler ways. Take BUNDLE, or the plan A/B/No question. We all know what these need to do, but we are encumbered by existing SDP - which is no single thing - in trying to reach a conclusion. Interconnectedness makes SDP hard. Harder than it needs to be. The main advantages of a new form of expression come from its ability to isolate problems. For instance, separating transport establishment was clearly a big win for Jingle in terms of flexibility, simplicity, capabilities. But those examples speak directly to your point. A new "language" might be unencumbered in a way that might make addressing these problems easier, it might even be more capable, but it is still just a new way of saying the same old thing. Offer/answer is the problem. It's a contrivance that can be chosen or rejected depending on how you plan to interact with the API. That embeds a negotiation engine into the browser, along with all the machinery for how to negotiate everything that SDP expresses. Negotiation is an extra, a feature that the IETF decided to add to the API to make it "easier to use". That wouldn't be a problem if it weren't mandatory, but it's the only way to do anything. (In contrast, CU-RTC-Web provides a negotiation feature, but it's an optional extra.) So SDP truly becomes a problem when coupled to offer/answer. The way that features interact become a problem for standardization, not because they interact with each other - interaction problems are what engineers are for - but because they are negotiated. And it's not the SDP negotiation that is the worst: it's the negotiation of what it means. We all know what it means, but I'm certain no two people "know" SDP the same way. That means another sort of negotiation. And those negotiations require that those engineers be sent to places like the IETF to argue endlessly, or play at politics. --Martin From matthew@matthew.at Mon Jul 1 12:22:21 2013 Return-Path: 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 7173611E8228 for ; Mon, 1 Jul 2013 12:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MIME_QP_LONG_LINE=1.396] 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 bUb0z61oePHR for ; Mon, 1 Jul 2013 12:22:15 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id B829311E8229 for ; Mon, 1 Jul 2013 12:22:15 -0700 (PDT) Received: from [10.210.183.55] (mobile-166-137-187-072.mycingular.net [166.137.187.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id DC80D1480C8; Mon, 1 Jul 2013 12:22:06 -0700 (PDT) References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B146) From: Matthew Kaufman Date: Mon, 1 Jul 2013 12:22:01 -0700 To: Ted Hardie Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 19:22:21 -0000 > Honestly, I have read it and I don't see how you avoid mandating some stan= dard > interface between the JS and browser. That needn't be SDP, but if it is c= ausing the > two sides to negotiate candidate transports and emit RTP, it's going to be= hard going > to avoid it being SDPNG. This lack of imagination among people designing the APIs we are supposed to u= se is disturbing. Have you read, just as an example, the CU-RTCWEB API? It achieves a browser A= PI without resorting to SDP or anything like it. If you insist on Offer/Answer *and* "opaque" blobs (that we all know people w= ill modify anyway), then sure, SDP looks attractive... But that's just a fai= lure to imagine a world where VoIP isn't based on SIP and SDP O/A. Matthew Kaufman (Sent from my iPhone)= From radhika.r.roy.civ@mail.mil Mon Jul 1 12:28:33 2013 Return-Path: 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 B7E2711E824B for ; Mon, 1 Jul 2013 12:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=1.200, 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 YUHtT5zJUyMx for ; Mon, 1 Jul 2013 12:28:28 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 38B5A11E81B4 for ; Mon, 1 Jul 2013 12:28:20 -0700 (PDT) Received: from UCOLHP3H.easf.csd.disa.mil (131.64.100.149) by edge-cols.mail.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 1 Jul 2013 19:28:19 +0000 Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.175]) by UCOLHP3H.easf.csd.disa.mil ([131.64.100.149]) with mapi id 14.03.0123.003; Mon, 1 Jul 2013 19:28:18 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Martin Thomson , Ted Hardie Thread-Topic: [rtcweb] New language (was: ... WebRTC JS Object API Model) (UNCLASSIFIED) Thread-Index: AQHOdo0W4p5/jY2SQ0CTa1Uyqx+u2plQLeSA Date: Mon, 1 Jul 2013 19:28:18 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49B13F7A@ucolhp9b.easf.csd.disa.mil> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0030_01CE766F.9B580F10" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New language (was: ... WebRTC JS Object API Model) (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 19:28:33 -0000 ------=_NextPart_000_0030_01CE766F.9B580F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Yes, the problems with capability negotiations with SDP had been well-known for the folks when H.323 (H.245) and SIP (SDP) were debated and when SIP RFC 3261 was created. Later on, SDP O/A RFC was created to help SDP to have some negotiation capabilities. Again, SDP could not provide any mechanisms for setting up of the multipoint conferencing call dynamically where media bridging is needed evolving from the two party point-to-point call that does not need any media bridging. Later on, it was felt impossible to modify SDP for multipoint conference call dynamically. So, it was decided that let us define a conference focus that is the central point is well known a priori to all and people will dial to that conference focus to set up the centralized multipoint conference call statically only in a star-like configuration. That is, we gave up the setup of the distributed conference call with sa mesh like configuration dynamically because of limitations of SDP signaling architecture. Now, if we keep the option that makes the WebRTC API is not 'hardwired' to SDP as the ONLY one as mandatory for media signaling protocol for media negotiations, then it will open up a huge innovative opportunities for all of us in the future to have much more richer multimedia conference capabilities. So, let us keep SDP as one of the many alternatives for negotiations for signaling of media capabilities (as opposed to ONLY one as mandatory that stops all future innovations knowing SDP's all those limitations - we cannot block our future innovativeness for real-time multipoint multimedia communications - future of real-time multimedia communications are yet to be imagined through creativity of the future generations). Best regards, Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Monday, July 01, 2013 2:58 PM To: Ted Hardie Cc: rtcweb@ietf.org Subject: [rtcweb] New language (was: ... WebRTC JS Object API Model) On 1 July 2013 11:17, Ted Hardie wrote: > Honestly, I have read it and I don't see how you avoid mandating some > standard interface between the JS and browser. That needn't be SDP, > but if it is causing the two sides to negotiate candidate transports > and emit RTP, it's going to be hard going to avoid it being SDPNG. This is an important argument, but it's only correct up to a point. And that is misleading. SDP does a lot of things that an API can do in far simpler ways. Take BUNDLE, or the plan A/B/No question. We all know what these need to do, but we are encumbered by existing SDP - which is no single thing - in trying to reach a conclusion. Interconnectedness makes SDP hard. Harder than it needs to be. The main advantages of a new form of expression come from its ability to isolate problems. For instance, separating transport establishment was clearly a big win for Jingle in terms of flexibility, simplicity, capabilities. But those examples speak directly to your point. A new "language" might be unencumbered in a way that might make addressing these problems easier, it might even be more capable, but it is still just a new way of saying the same old thing. Offer/answer is the problem. It's a contrivance that can be chosen or rejected depending on how you plan to interact with the API. That embeds a negotiation engine into the browser, along with all the machinery for how to negotiate everything that SDP expresses. Negotiation is an extra, a feature that the IETF decided to add to the API to make it "easier to use". That wouldn't be a problem if it weren't mandatory, but it's the only way to do anything. (In contrast, CU-RTC-Web provides a negotiation feature, but it's an optional extra.) So SDP truly becomes a problem when coupled to offer/answer. The way that features interact become a problem for standardization, not because they interact with each other - interaction problems are what engineers are for - but because they are negotiated. And it's not the SDP negotiation that is the worst: it's the negotiation of what it means. We all know what it means, but I'm certain no two people "know" SDP the same way. That means another sort of negotiation. And those negotiations require that those engineers be sent to places like the IETF to argue endlessly, or play at politics. --Martin _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0030_01CE766F.9B580F10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzA3MDExOTI4MTZaMCMGCSqGSIb3DQEJBDEWBBRY8Cj78q0lCF0H9h+r/MQp k1mYtzBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAE+jOoWThMeNtgF1se8rSPkWQNRauR2EZoSbrB5je2xpezr1Fr4Xbkwyajo7aUrMPr5p jS9VDBX9SmcweLHc2F1u3HLYfeATWj8x1VQWkmCI5JVvfBVN0Qyi5udthBk0j4lI40DDhTJgSsGi g4WTlnlfB9vLToD6iFnUSI0/0BVrbMl5meIBk2oJ++M+vAda7A4cuNLrbonrXN0rKpATixT1Qj/F koN7UQZVxmkKNr2nYf3Fr1eOxtyuZzI8Yb+9YFT+KAemMbs37oxlc4Vh5klOvCBouj3VLh2t3vA0 sI7tQ6zeGPBOMEXCcOrU9hnzR8KZLVF/fqInCr+U3V6K3msAAAAAAAA= ------=_NextPart_000_0030_01CE766F.9B580F10-- From ted.ietf@gmail.com Mon Jul 1 13:11:27 2013 Return-Path: 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 2586711E822D for ; Mon, 1 Jul 2013 13:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 NIsFVYg5kvDR for ; Mon, 1 Jul 2013 13:11:26 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1C70D11E8229 for ; Mon, 1 Jul 2013 13:11:25 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so4105680wgg.10 for ; Mon, 01 Jul 2013 13:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Ea9pQKW3SRMyITj+0hPh/g3nsiMcOr1r7oIsLgIWuI=; b=u+d6dzlUMOLqMDNL0WxXlvXrX4Gw3HUMVfC8pWp0f5q8yuOIzc08bm6mbVHDRC8fSZ G/CgJOtQbc4835sYiIugIiqBdW40VAZvKbxXDlo1d7hAr9aOXa3HRljBHwELau3CBmMm oahUWuMwt+ddJi03Yq/ywptMds9bW+rHoBULVNuuk+6naU4gPB2fGRhUKmJYjmRmhSGX CFD8Vv9yfraZCb50OAxZJMUvGiJQMShzKtPCTw+Iru4Njov4Bj7wlL2Q+ro4bQH078zA 0f0oJs5EjSVpnXffHsLxVhHDsC6lAGTDa1p7H58wL6DH3k+5/WBS4REJSxNj5kNtEAj9 ecSw== MIME-Version: 1.0 X-Received: by 10.194.172.228 with SMTP id bf4mr20771098wjc.36.1372709483929; Mon, 01 Jul 2013 13:11:23 -0700 (PDT) Received: by 10.227.164.137 with HTTP; Mon, 1 Jul 2013 13:11:23 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> Date: Mon, 1 Jul 2013 13:11:23 -0700 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: multipart/alternative; boundary=089e013c6c122b6d7f04e078d5e4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 20:11:27 -0000 --089e013c6c122b6d7f04e078d5e4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 12:22 PM, Matthew Kaufman wrote= : > > > Honestly, I have read it and I don't see how you avoid mandating some > standard > > interface between the JS and browser. That needn't be SDP, but if it i= s > causing the > > two sides to negotiate candidate transports and emit RTP, it's going to > be hard going > > to avoid it being SDPNG. > > This lack of imagination among people designing the APIs we are supposed > to use is disturbing. > > Have you read, just as an example, the CU-RTCWEB API? It achieves a > browser API without resorting to SDP or anything like it. > > I have read it, though I see from the date on it that it has been updated since the last time I did so. You are right that this does not look anything like SDP, and it is therefore not clear to apply the moniker SDPNG to it. But CU-RTCWEB also contains elements that are standardized to meet similar requirements, which I believe I=F1aki is arguing is not needed. To put it in CU-RTCWEB terms, I don't see how not having a standardized version of something like RtpStreamDescription, RtpExtension, or CodecDescription scales, since the result is that browser must understand whatever approach the JS application chooses to use for those. To restate this: having the JS application to JS application API surface not be standardized works because the private agreements can be expressed in the application; having the JS application to browser interface be not be standardized doesn't seem to me to work at scale. It could be done by having an independent browser extension for every site that wants to use a specialized API, but that hardly seems to meet the goals of the group. Once again, no hats or company swag on, Ted If you insist on Offer/Answer *and* "opaque" blobs (that we all know people > will modify anyway), then sure, SDP looks attractive... But that's just a > failure to imagine a world where VoIP isn't based on SIP and SDP O/A. > > Matthew Kaufman > > (Sent from my iPhone) --089e013c6c122b6d7f04e078d5e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2013 at 12:22 PM, Matthew Kaufman <matthew@matthew.at&= gt; wrote:

> Honestly, I have read it and I don't see how you avoid mandating s= ome standard
> interface between the JS and browser. =A0That needn't be SDP, but = if it is causing the
> two sides to negotiate candidate transports and emit RTP, it's goi= ng to be hard going
> to avoid it being SDPNG.

This lack of imagination among people designing the APIs we are suppo= sed to use is disturbing.

Have you read, just as an example, the CU-RTCWEB API? It achieves a browser= API without resorting to SDP or anything like it.


I have read it, though I see from the date on it = that it has been updated since the last time I did so. =A0You are right tha= t this does not look anything like SDP, and it is therefore not clear to ap= ply the moniker SDPNG to it. =A0But CU-RTCWEB also contains elements that a= re standardized to meet similar requirements, which I believe I=F1aki is ar= guing is not needed. =A0To put it in CU-RTCWEB terms, I don't see how n= ot having a standardized version of something like RtpStreamDescription, = =A0RtpExtension, or CodecDescription scales, since the result is that brows= er must understand whatever approach the JS application chooses to use for = those.

To restate this: =A0having the JS application to JS application API sur= face not be standardized works because the private agreements can be expres= sed in the application; having the JS application to browser interface be n= ot be standardized doesn't seem to me to work at scale. It could be don= e by having an independent browser extension for every site that wants to u= se a specialized API, but that hardly seems to meet the goals of the group.=

Once again, no hats or company swag on,

Ted
=A0

If you insist on Offer/Answer *and* "opaque" blobs (that we all k= now people will modify anyway), then sure, SDP looks attractive... But that= 's just a failure to imagine a world where VoIP isn't based on SIP = and SDP O/A.

Matthew Kaufman

(Sent from my iPhone)

--089e013c6c122b6d7f04e078d5e4-- From ibc@aliax.net Mon Jul 1 13:38:20 2013 Return-Path: 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 8CB7611E8254 for ; Mon, 1 Jul 2013 13:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 T4U6Dw+DqvGS for ; Mon, 1 Jul 2013 13:38:15 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4E40111E8241 for ; Mon, 1 Jul 2013 13:38:15 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so2368473qab.1 for ; Mon, 01 Jul 2013 13:38:14 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=flT+uKnwPRR/TV5D4eVAcld1uF9t6e9zfSU1mgvXuws=; b=B6cxqwDVkMtZkyNaIH4AYzVBFmMoQc8S/qKkeLc11CxsjFjF0fJcYn1lM3xB4IrHBu BQtsDj8Fpjq5FbFJUjvGVgyn68srz16/Hwp91/pXlxjNH7oC2hINdcYnbvKnQiqBSt63 tVanm0yhMTjbdCW4AmeSA1rF/Ubj1/VcWzV1gXImEAfuN0KkfxAju3y8qTgsNdYLx1Kh gZHdaXy1he2TYQhquSP7UTwLq8D339WHzV/dvERjQaiB6n3Bo6V48MUZxzsK6mxnTCzS 96cduldW5tHqS6uIPfYTNDyxVkeiS48VrZETExqbkgukD9L3QwyXrYj7g4+cSaLdabmq TXgQ== X-Received: by 10.49.35.108 with SMTP id g12mr34761246qej.86.1372711094552; Mon, 01 Jul 2013 13:38:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 1 Jul 2013 13:37:54 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 1 Jul 2013 22:37:54 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnTFvVsDFc+x9dx4VHzHD1FIjR/5yxeIIxJtD8ITjWea2KLJBrsv8M2XpB5Gx5yblT+5lHB Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 20:38:20 -0000 2013/7/1 Stefan H=C3=A5kansson LK : > What if first browser generated a JS Object that said (for this example > we assume one single audio track) it preferred to send audio using > Opus2.0 but could also do Opus and G.711. If the second browser (which > has not yet been upgraded) could only decode Opus and G.711, would it > not have to tell the first browser about this? > > Are you perhaps assuming a capability exchange of some sort before any > media can be set up? The fact that a capability exchange or media signaling negotiation exists does not mean that it must be based on a opaque blob which is unmanageable at JS level. The JS app should be able to understand *what* exactly it is sending in-the-wire, and for that purpose a opaque blob is not a ellegant solution. Instead a JS Object based API (like *any* WWW API) makes sense. And then the JS app can decide how to encode/serialize/whatever such a media information in-the-wire (and yes, it can be into a SDP, but a SDP created by the JS library because the author chose it, while others can use whatever format or send the information "splitted" into different requests or whatever. Of couse the SDP O/A model is a valid model, and of course SIP is a valid model (which carries the SDP exchange), but that is not the only one. IMHO the IETF/W3C should not mandate like-SIP-models for every future RTC applications running in the web. Best regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jul 1 13:59:43 2013 Return-Path: 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 E88A011E825F for ; Mon, 1 Jul 2013 13:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 GF5D56sCXuQe for ; Mon, 1 Jul 2013 13:59:39 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9F21211E827F for ; Mon, 1 Jul 2013 13:59:39 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so3152733qcx.21 for ; Mon, 01 Jul 2013 13:59:39 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=x6DIItagjYFaG3n8Cjs9NWMHv4+f3FeHoA2v3OalNyY=; b=XTkOCWb0Xud1B5gfGi5GkQGUUvRR9CSZUGJG+UrTIQozXV4wK+jkLfj92oDkPAjrt2 fqJtVOk/0j1atI4z1pB4jMsPcOUZ+JuMIJrY+nI7CGKtIMHGEpilKqNEmu+zDIfAAuJQ ZtpZYTNCzmzmdFpkgQmRkTGGRiWmQ/xhru/fL4uaRsjxyBXbxWcqBsxNNinW09EAOiGk URq4JOvDHCvJm+2Qwpdlr/TCdjlP2G/chAJPWPtZvBou4lvewmGImqJbAk9653YIYgmJ e15Vu5oH/BYdGWNO6Qz7jz6tnY9+Sb+y+dvg1YwkAcCFCjp8xHFUtOlgvon5BAKALZV/ J2CA== X-Received: by 10.224.177.201 with SMTP id bj9mr34731839qab.14.1372712378878; Mon, 01 Jul 2013 13:59:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 1 Jul 2013 13:59:18 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 1 Jul 2013 22:59:18 +0200 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmkTp06rNJf5EpIMj7UFKN/3VgiZzBUFQj1L5KdepjeRsN+8b6+GQUMhy3O5BPGwcDA6eQ2 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 20:59:44 -0000 2013/7/1 Ted Hardie : > On Mon, Jul 1, 2013 at 10:22 AM, I=C3=B1aki Baz Castillo = wrote: > > Preface: I have read the document you refer to, and I find it personally= a > lot less clear than you do. While I would welcome specific pointers when= I > ask questions, more elucidation is needed for me. Thanks for understandi= ng. Sure Ted, and thanks a lot for reading the draft. >> Of course, I mean "the media signaling". But that is not just about >> "in-the-wire". Current WebRTC specs mandate that the information unit >> exchanged between the JS app and the WebRTC stack must be a SDP blob. >> >> What I mean is: >> >> - The JS app uses the WebRTC API to retrieve a JS Object (or Objects) >> with transport and media info. >> > > Retrieve from where? I don't want to design an API in a few lines because I may be 100% wrong, but (very) basically: The JS app: - Calls getUserMedia(). - Creates a PC instance. - Provides the PC with the MediaTracks obtained from getUserMedia(). - Calls to some API method*s* in PC to retrieve ICE transport information (which is obtained as JS Object, with attributes representing the corresponding fields of a ICE "line"). - Calls to some other API method*s* in PC to get the list of supported codecs and tells the PC, via another PC API method, the preference order. - Calls to some other API method*s* in PC to get local MediaStream and/or MediaTracks instances (i.e. to render local video). - Calls to some other API method*s* in PC to get crypto/DTLS information (an Object with the appropriate attributes fully defining such an information). - ...and so on. And the the JS app serializes all the retrieved information and encodes/serializes/whatever it into a JSON body, XML, etc etc, and sends it in-the-wire (or splittes it into various chunks of information to be send separately). > Does the browser generate these at the direction of > the JS application, > or do you believe it generates them when media sources are connected. Ho= w > are data sources > created? I don't understand the question. In the current SDP-based model you get all the media/transport information when you get the SDP (SessionDescription instance) from the PC, right? and then you send it in-the-wire and ICE stuff starts. Some here, but instead of passing a horrile opaque blob, let's use JS Objec= ts. NOTE: This is just one of the various changes/improvements the draft describes. It is not all about the interface between the JS layer and the WebRTC stack in the browser. >> - The JS app serializes such a information in any custom way defined >> by the website developer (this can be a JSON body, XML, SDP! or >> whatever). >> >> - The JS app sends the information to the remote peer. >> >> - The JS app of the remote peer decodes the information (since it is a >> JS app designed by the same domain/website) and extracts all the >> transport/media fields. >> >> - The JS app of the remote peer creates a local PC and makes calls to >> API methods of PC for passing those transport/media fields. >> >> - ...and remove O/A mandate. >> >> But honestly, all of this is really well described and exposed in the >> draft: >> >> >> http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-ration= ale-00 >> >> >> > > None of the above appears to touch on the API which uses SDP in the curre= nt > design; that's between the JS and the browser. In fact the proposed API between the JS and the browser is what encourages that the JS app can send whatever it wants in-the-wire. Anyhow I don't fully understand what you mean with "the API which uses SDP in the current design". Do you mean setLocalDescription (which is provided with an opaque blob) and getLocalDescription (which provides an opaque blob)? >> http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-ration= ale-00 >> > > Honestly, I have read it and I don't see how you avoid mandating some > standard > interface between the JS and browser. That needn't be SDP, Of course we need a standard interface (this is: API) between the JS and browser. That's why we are proposing a "JS Object API rationale". But we need a *real* JS API (which means functions that returns JS Objects and are provided with JS Objects) rather than the current API that just works by passing an opaque/unmanageable blob between JS and browser (in both directions). Best regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jul 1 14:01:54 2013 Return-Path: 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 2167C11E8295 for ; Mon, 1 Jul 2013 14:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 wraEL5bXUra5 for ; Mon, 1 Jul 2013 14:01:49 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id F196C11E8291 for ; Mon, 1 Jul 2013 14:01:48 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so3154301qcx.21 for ; Mon, 01 Jul 2013 14:01:48 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=3rqeM8TX4Z+cYqtJ7xQ6SYqnrEzr92M4YHWzIYNX8fg=; b=i3qKViKPmjf0kzdoAM5b3Ndtl8samjh+3zxCZWhwhbCDh4bkXhEotgIqb6+gtSW9gZ DmbhcWVzfqozmDFqG1OSBumG+zqeSWcIb8tnyXW7MO85D/3jXFzz5gjFdO6maIshrPps YXPXrtVKgLsA4XxUmWCLcK4l+AuZmO5ddKIeQcibtT45XRAjUYR6UrPlmtK4f72cr4zP z/ZFZ3yuP+bOgl1O4nVizP2WQJRv3tr/gTHCgttOmsV3Vc4sbRB9H/55oWLWSZ8Qs7qq sO/OImXOsbzPoa0zkdE4ZKxc9aTw+aqxl+9nZvDwKj42rkInoOo4S5+WJmUk++u2NOAb 6mcg== X-Received: by 10.49.117.195 with SMTP id kg3mr34047898qeb.68.1372712508516; Mon, 01 Jul 2013 14:01:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 1 Jul 2013 14:01:28 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 1 Jul 2013 23:01:28 +0200 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnc5Ou7nGvidQnHLIgg6SiAK5ctqSkbvd8JwumlqYumL0cB12wuM+yH3zcVTGhayM/IekX/ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 21:01:54 -0000 2013/7/1 Ted Hardie : > You are right that this does not look anything like SDP, and it is theref= ore > not clear to apply the moniker SDPNG to it. But CU-RTCWEB also contains > elements that are standardized to meet similar requirements, which I beli= eve > I=C3=B1aki is arguing is not needed. May be I explained it wrong, but as said in my previous mail, of course some kind of *REAL* JS Object-based API is required to interface between JS and browser. -- I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Tue Jul 2 00:21:34 2013 Return-Path: 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 830AA11E8390 for ; Tue, 2 Jul 2013 00:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 01Beu6nEtd3E for ; Tue, 2 Jul 2013 00:21:24 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85711E83F5 for ; Tue, 2 Jul 2013 00:21:20 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-cf-51d27f6e4b01 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 09.9A.06741.E6F72D15; Tue, 2 Jul 2013 09:21:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Tue, 2 Jul 2013 09:21:18 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Roman Shpount Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model Thread-Index: AQHOcibV+w71mSCXSkiQxLiPakqfXQ== Date: Tue, 2 Jul 2013 07:21:17 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3098BA@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+JvrW5+/aVAg2VdzBbT99lYzLgwldli 7b92dgdmj3MN79k9liz5yeRxa0pBAHMUl01Kak5mWWqRvl0CV8bia5UFb0Qqjt2YwNzA+EWg i5GTQ0LARGLuhe2MELaYxIV769m6GLk4hAQOM0p0/v7MCpIQEljIKDH1uyWIzSYQKLF13wI2 EFtEQFXi7/fJTCA2s0CCxPsZl5lBbGEBG4m+D5+B4hxANbYS29pYIcr1JOZ8XskOYrMIqEgc Pd7EDlLCK+ArMWlzJsSml6wSJ7oMQGxGoHO+n1oDNV1c4taT+UwQZwpILNlznhnCFpV4+fgf K4StJPFjwyUWiHo9iRtTp7BB2NoSyxa+BqvnFRCUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZ VjGy5yZm5qSXG25iBEbFwS2/dXcwnjoncohRmoNFSZx3k96ZQCGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2MkqpOu4IDJGLzQ660JzFovtOZpNZhm/lRhttkiUSGcMKrBzYZhyd8uHfE371P /fL6qybcxyRnJ6b+Mr7Ztyr4/dy0FoNL27bf8MpO3ssy93RLkmnYgdyCMouTfAzx8YxrHi6/ qCikfY7nTayt2pL+53xBH7pW7i+QP+sU2v86WP34s1TBZapKLMUZiYZazEXFiQAOdBPmWAIA AA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 07:21:35 -0000 On 2013-07-01 20:24, Roman Shpount wrote:=0A= > On Mon, Jul 1, 2013 at 1:33 PM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > What if first browser generated a JS Object that said (for this examp= le=0A= > we assume one single audio track) it preferred to send audio using=0A= > Opus2.0 but could also do Opus and G.711. If the second browser (whic= h=0A= > has not yet been upgraded) could only decode Opus and G.711, would it= =0A= > not have to tell the first browser about this?=0A= >=0A= > Are you perhaps assuming a capability exchange of some sort before an= y=0A= > media can be set up?=0A= >=0A= >=0A= > Any API that we propose would include methods to expose browser=0A= > capabilities (ie list of available codecs, with default payload type,=0A= > payload name, clock rate, number of channels, and preferred codec=0A= > parameters). Generation of SDP c line, rtpmap, and fmtp lines from this= =0A= > would be trivial, as well as generation of other media descriptions for= =0A= > XMPP or other negotiation protocols.=0A= >=0A= > In other words, we are not removing the need for negotiation. All we=0A= > want is to unbundle it from single offer/answer exchange with single=0A= > string blob into separate methods where transport negotiation (ie DTLS,= =0A= > SRTP, and ICE candidates), mapping transport to streams (ie any sort of= =0A= > bundle related mapping remote address, SSRC, payload or others), and=0A= > media encoding/decoding (ie send and receive codecs, codec parameters,=0A= > payload times, etc) are all negotiated separately and independently.=0A= =0A= Roman, thanks for clarifying. Personally (wearing no hat) I think =0A= splitting things up makes a lot of sense. In fact, our first prototype =0A= browser (back in early 2011) was sort of implemented this way: each =0A= MediaStream was described and negotiated separately. We used SDPs for =0A= the purpose though (each addStream lead to a separate SDP O/A setting up = =0A= that unidirectional MediaStream with its tracks).=0A= =0A= But I think we should not underestimate the work needed to describe all =0A= the nitty gritty details using another "language" than SDP.=0A= =0A= > This is what is happening with the API anyway with trickle ICE and=0A= > no-plan proposal adding ability to update transport and media parameters= =0A= > once the initial connection is established. All we want is to extend the= =0A= > same logic to the initial connection establishment,=0A= > _____________=0A= > Roman Shpount=0A= =0A= From ibc@aliax.net Tue Jul 2 01:02:11 2013 Return-Path: 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 6C7BE11E8404 for ; Tue, 2 Jul 2013 01:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 V21U3Sm2AapY for ; Tue, 2 Jul 2013 01:02:06 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4847711E83D5 for ; Tue, 2 Jul 2013 01:02:06 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so2644983qab.0 for ; Tue, 02 Jul 2013 01:02:05 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=QFXm6TSc6NwsBkurC5ApY0tusbJST5eBdt1AdcJ8x7g=; b=L+af60npFK88fZYkobYeNHWXoI7cRJHddxOXlgG2BZbxeIyHvRWDnlCpAzwVs1I3lF ZRUVQJfgRN6cKJl2XyqT+jCOF4Uwu6iQtkS/0ZYgiAewGyXsjVHaDJ5jru+JRTPJM/i0 z98GbA5gi8BJN5ta36e/9NdOItWdMYf1VKgSwaRpi4wbzSkjc/gPZMIdsKjXGT8wOicN P62UqY92K0qY02J/BCFCqdGmJlrsCWwwHsjyuXDGZ3c0YgkkT3Kdzi3xsECS0fjt/OFf efwlg2erCtkHPlCuc90Gnmtvk4wch241SPzpDIQNSsu7RKnJY0TreUKh5dbSxPb6pFOv ogsg== X-Received: by 10.224.182.79 with SMTP id cb15mr37880464qab.48.1372752125762; Tue, 02 Jul 2013 01:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 2 Jul 2013 01:01:45 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C3098BA@ESESSMB209.ericsson.se> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C3098BA@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 2 Jul 2013 10:01:45 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn0TDHmeTjuNfxJbLTCrcLAaeq2ELmm57GNH2EAxNELRoU6dDsu1MrsMcO702u+zCY6tmxR Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 08:02:11 -0000 2013/7/2 Stefan H=C3=A5kansson LK : > But I think we should not underestimate the work needed to describe all > the nitty gritty details using another "language" than SDP. Hi Stefan, As said multiple times we are not proposing a replacement for SDP. Passing an opaque blob string between browser and WebRTC is not the only solution, even more, I don't consider that an "API". If after reading the draft you have understood that we are proposing a replacement for SDP then we've done something wrong. Regards. -- I=C3=B1aki Baz Castillo From tim@phonefromhere.com Tue Jul 2 01:31:37 2013 Return-Path: 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 641A111E843B for ; Tue, 2 Jul 2013 01:31:37 -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 GOSokdFHm3xj for ; Tue, 2 Jul 2013 01:31:31 -0700 (PDT) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by ietfa.amsl.com (Postfix) with ESMTP id BB19711E843A for ; Tue, 2 Jul 2013 01:31:29 -0700 (PDT) Received: (qmail 47372 invoked from network); 2 Jul 2013 08:31:27 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp004.apm-internet.net with SMTP; 2 Jul 2013 08:31:27 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id C090818A06B2; Tue, 2 Jul 2013 09:31:27 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id A1E6818A06AB; Tue, 2 Jul 2013 09:31:27 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1CE3157B-CA1A-4B17-BA73-ACB78C4C5A4E" From: Tim Panton In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C3098BA@ESESSMB209.ericsson.se> Date: Tue, 2 Jul 2013 09:31:26 +0100 Message-Id: References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C3098BA@ESESSMB209.ericsson.se> To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= X-Mailer: Apple Mail (2.1283) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 08:31:37 -0000 --Apple-Mail=_1CE3157B-CA1A-4B17-BA73-ACB78C4C5A4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2 Jul 2013, at 08:21, Stefan H=E5kansson LK wrote: >=20 > But I think we should not underestimate the work needed to describe = all=20 > the nitty gritty details using another "language" than SDP. Conversely we shouldn't underestimate (again) the difficulty of = describing all the nitty gritty details in SDP.=20 I have the sense that we may have pushed the flexibility of SDP beyond = it's elastic limit. I think that over the last year we have discovered that a dynamically = programmable browser is a fundamentally different beast from a deskphone and that what suits = one may well not suit the other. Tim. --Apple-Mail=_1CE3157B-CA1A-4B17-BA73-ACB78C4C5A4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

But I think we = should not underestimate the work needed to describe all
the nitty = gritty details using another "language" than = SDP.

Conversely we shouldn't = underestimate (again) the difficulty of describing all = the
nitty gritty details in = SDP. 

I have the sense that we may have = pushed the flexibility of SDP beyond it's elastic = limit.

I think that over the last year we have = discovered that a dynamically programmable browser
is a = fundamentally different beast from a deskphone and that what suits one = may well not suit the = other.

Tim.

= --Apple-Mail=_1CE3157B-CA1A-4B17-BA73-ACB78C4C5A4E-- From stefan.lk.hakansson@ericsson.com Tue Jul 2 03:16:12 2013 Return-Path: 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 2B82E11E846B for ; Tue, 2 Jul 2013 03:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.82 X-Spam-Level: X-Spam-Status: No, score=-3.82 tagged_above=-999 required=5 tests=[AWL=-1.521, BAYES_00=-2.599, 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 IIjTClbgBAY4 for ; Tue, 2 Jul 2013 03:16:07 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D81E911E8476 for ; Tue, 2 Jul 2013 03:16:04 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-5e-51d2a86203e2 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 7F.F5.11907.268A2D15; Tue, 2 Jul 2013 12:16:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Tue, 2 Jul 2013 12:16:02 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Saverio Mascolo Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVw== Date: Tue, 2 Jul 2013 10:16:02 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C309A30@ESESSMB209.ericsson.se> References: <51C96E36.2000907@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B1C308D3B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvrW7yikuBBrt3MFoc6+tis1j7r53d 4vi/0+wOzB5XJlxh9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mv7M+sFcMMuq4tmuRYwN jD06XYycHBICJhLT399jg7DFJC7cWw9mCwkcZZSY/s6ki5ELyF7IKPFv5nVWkASbQKDE1n0L gIo4OEQE9CXebUwGCTMLBEv0dk0GKxEW0JVoOL4GbI6IgJ7EwucvWGDs3fs/MoPYLAIqErOO /AOr5xXwlfjecoodYtdvRombj3azgyQYgQ76fmoNE8QCcYlbT+YzQRwqILFkz3lmCFtU4uVj iEESAkoSPzZcYoGo15O4MXUKG4StLbFs4WtmiGWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEj yypGjuLU4qTcdCODTYzACDm45bfFDsbLf20OMUpzsCiJ827ROxMoJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgXFeV9lN9nTpVbVPOdX8Fuw6Kqz5rr7Lp+//AbtHgR8dv6wrzdVtWtcxJ1Gj oFLmitCRzs/vJ1pKT3j+4cf0VYc05wfcmbZHZ1lskrnn3NSrW+df2t5xPTR+zT6F8+cLvu/J nRm+j4ffoPfKxTSfB/9rvsxe9XrhiY/hZnsY/bkyLmatef1hsfx1JZbijERDLeai4kQAPIes 3V4CAAA= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 10:16:12 -0000 On 2013-07-01 19:10, Saverio Mascolo wrote:=0A= > an evaluation of how h264 and vp8 are able to match a changing quality=0A= > would be interesting=0A= =0A= Such an evaluation would be very hard to do. The H.264 standard does not = =0A= specify any encoder behavior, only the decoder is specified. This means =0A= that the encoder can be implemented freely, as long as it produces a =0A= bitstream compliant to the standard. Specifically, there is no =0A= specification in H.264 on how to implement the rate controller. Thus the = =0A= rate control mechanisms of two different H.264 encoder implementations =0A= could react differently to a change in scene complexity.=0A= =0A= There is a wealth of H.264 implementations on the market today. Some may = =0A= have implemented a better rate control mechanism than x264, some may =0A= have implemented a worse variant. Testing x264 versus the WebM vp8 =0A= implemenation with rate control turned on may give some information =0A= about the relative merits of these two rate control implementations =0A= (although the rate control gives rise to so much measurement noise so =0A= even that is hard to do) but it says very little about how the H.264 =0A= standard compares to the vp8 specification in situations where the scene = =0A= complexity varies.=0A= =0A= =0A= >=0A= >=0A= > On Sat, Jun 29, 2013 at 3:17 PM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > On 6/25/13 12:17 PM, Harald Alvestrand wrote:=0A= > > Again - thanks for releasing this openly!=0A= > >=0A= > > I ran the scripts (with a few tweaks; you run on a system where sh= is=0A= > > bash, not dash, for instance), and got the same numbers within=0A= > +/- 0.5%=0A= > > (probably some binary version skew);=0A= >=0A= > I re-run the scripts on another computer with another OS today, and I= =0A= > get exactly the same results as Bo sent out. I noted however that if = the=0A= > input clips are not cut at 10s (but used in their entire length) the= =0A= > results get slightly different, but within +/- 0.5%. Can this be the= =0A= > reason why you get slightly different numbers?=0A= >=0A= >=0A= > > we may have disagreements on the=0A= > > parameters to use, but we agree on the numbers those parameters=0A= > produce.=0A= > >=0A= > > (I have since modified the Google framework to include a script th= at=0A= > > pulls in the sources for the needed binaries and compiles them -= =0A= > if you=0A= > > want to make 100% sure people are working from the same sources,= =0A= > you may=0A= > > want to rebase to a newer version of the comparision toolkit.)=0A= > >=0A= > > On 06/22/2013 03:41 PM, Bo Burman wrote:=0A= > >> Hi all,=0A= > >>=0A= > >> We have had a look at Google's comparison between VP8 and H.264= =0A= > constrained baseline that was posted on April 3rd=0A= > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg07028.html).= =0A= > This post contains, as the one mentioned above (and if the=0A= > attachments make it to the list), information on the exact tools and= =0A= > options used for encoding and should thus be repeatable by anyone=0A= > interested.=0A= > >>=0A= > >> As was already stated by others on this list, one major problem= =0A= > is that Google's test involves the rate control mechanism. Typically= =0A= > codecs are measured with rate control turned off, since it acts as a= =0A= > huge noise on the measurement. Instead we propose to compare the=0A= > codecs using fixed qp-levels. The qp-level is the quantization=0A= > parameter that affects the rate/distortion tradeoff. Comparing using= =0A= > fixed qp-levels is what has been used when benchmarking HEVC against= =0A= > H.264 in the JCT-VC standardization, for instance. We are going to=0A= > select a codec (essentially bit stream format), not a rate control=0A= > mechanism: Once the codec is selected you can choose whatever rate=0A= > control mechanism you wish.=0A= > >>=0A= > >> We used Google's excellent framework as the baseline and changed= =0A= > the parameter settings in order to make it possible to measure using= =0A= > fixed qp. We used the same sequences, but limited them to the first= =0A= > 10 seconds since they varied from 10 seconds to minutes; this also=0A= > eased computation time.=0A= > >>=0A= > >> We used two H.264 encoder implementations: X264, which is an=0A= > open-source codec that can operate in everything from real-time to=0A= > slow, and JM which is the reference implementation that was used to= =0A= > develop H.264. JM is very slow but attempts to be very efficient in= =0A= > terms of bits per quality. The results were as follows:=0A= > >>=0A= > >> X264 baseline vs VP8: H.264 wins with 1%=0A= > >> JM baseline vs VP8: H.264 wins with 4%=0A= > >>=0A= > >> Running times:=0A= > >> X264: 1 hour 3 minutes=0A= > >> VP8: 2 hours 0 minutes=0A= > >> JM: order of magnitude slower=0A= > >>=0A= > >> It is interesting to note that the measurements are more stable= =0A= > in the new test; the variance of the percentages for the sequences=0A= > is now around 70, down from around 700 in Google's test of April=0A= > 3rd. We believe this is due to the removal of the rate controller,= =0A= > which acts like noise on the measurements.=0A= > >>=0A= > >> We also tried setting H.264 to constrained high (no interlace=0A= > and no B-pictures, compared to high). The results were then:=0A= > >>=0A= > >> X264 constrained high vs VP8: H.264 wins with 25%=0A= > >> JM constrained high vs VP8: H.264 wins with 24%=0A= > >>=0A= > >> We also note that the script that Google provided to calculate=0A= > the rate differences ("BD-rate") does not give exactly the same=0A= > numbers as the JCT-VC-way of calculating BD-rate. The main=0A= > difference is that the JM score for constrained high is better=0A= > (around 29%) if the JCT-VC way of calculating BD-rate is used.=0A= > >>=0A= > >> In summary we think that proper testing can conclude that there= =0A= > is no clear performance advantage to any codec between VP8 and H.264= =0A= > baseline. When comparing VP8 against H.264 constrained high on the=0A= > other hand, it seems like there is an advantage for H.264=0A= > constrained high.=0A= > >>=0A= > >> The attached file includes the files necessary to reproduce the= =0A= > test.=0A= > >>=0A= > >> Best Regards,=0A= > >>=0A= > >> Bo Burman=0A= > >>=0A= > >>=0A= > >> _______________________________________________=0A= > >> rtcweb mailing list=0A= > >> rtcweb@ietf.org =0A= > >> https://www.ietf.org/mailman/listinfo/rtcweb=0A= > >=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= >=0A= >=0A= =0A= From radhika.r.roy.civ@mail.mil Tue Jul 2 03:44:40 2013 Return-Path: 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 D109021F9E6D for ; Tue, 2 Jul 2013 03:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, 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 IzOBYSppF1gB for ; Tue, 2 Jul 2013 03:44:34 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 879C421F944F for ; Tue, 2 Jul 2013 03:44:07 -0700 (PDT) Received: from UCOLHP3H.easf.csd.disa.mil (131.64.100.149) by edge-cols.mail.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 2 Jul 2013 10:44:05 +0000 Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.175]) by UCOLHP3H.easf.csd.disa.mil ([131.64.100.149]) with mapi id 14.03.0123.003; Tue, 2 Jul 2013 10:44:04 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Tim Panton , =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model (UNCLASSIFIED) Thread-Index: AQHOcibVdEuE4rVfokmLdlNIiK8D3plRGMcAgAAixSA= Date: Tue, 2 Jul 2013 10:44:03 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49B1412B@ucolhp9b.easf.csd.disa.mil> References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C3098BA@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CE76EF.88EBF730" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 10:44:41 -0000 ------=_NextPart_000_0000_01CE76EF.88EBF730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED Caveats: NONE Inline [RRR] -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Tim Panton Sent: Tuesday, July 02, 2013 4:31 AM To: Stefan H=E5kansson LK Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model On 2 Jul 2013, at 08:21, Stefan H=E5kansson LK wrote: =09 But I think we should not underestimate the work needed to describe all=20 the nitty gritty details using another "language" than SDP. =09 Conversely we shouldn't underestimate (again) the difficulty of = describing all the nitty gritty details in SDP.=20 I have the sense that we may have pushed the flexibility of SDP beyond = it's elastic limit. [] I think that over the last year we have discovered that a dynamically programmable browser is a fundamentally different beast from a deskphone = and that what suits one may well not suit the other. Tim. Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0000_01CE76EF.88EBF730 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzA3MDIxMDQ0MDBaMCMGCSqGSIb3DQEJBDEWBBR87YmnHP1FzN94XboVdpTf Hwf3oTBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBACdOoi58T94GFN9bZ+zdWKRiZT5kN9JEWnkImB15pThNygW1L/vEQh/cUrID2FQ3f/IE CekLdqYcpmmzcaCF9NINmxSxYxlKDS9c5H735YAxYig6cwANnGdu6yA0k7IqGhlfQ4pyuhOQC4Ux Ytei1PneaAzSq5n+GBDcTxV88aEdAnR+tBb1bSpwN10I0TLokUPEkJKIq0dU6D8jl+LDMMLwmA0O jGBp/Agesqm60J96VeUXBdZS7E2FRYCsapmJtxbRmYs3R+vORm1Sb03wCrxqpNg1V2XarkaVbP1l cNQPr+pO8GQkxJHF57WNZJLGlUMj2lXwXsQh4676/zx51acAAAAAAAA= ------=_NextPart_000_0000_01CE76EF.88EBF730-- From robin@hookflash.com Tue Jul 2 05:23:09 2013 Return-Path: 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 422A611E810F for ; Tue, 2 Jul 2013 05:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 eCnWKzZzTMoD for ; Tue, 2 Jul 2013 05:23:04 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id B00E811E80A2 for ; Tue, 2 Jul 2013 05:23:04 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so12292833ied.0 for ; Tue, 02 Jul 2013 05:23:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=sn42e4QrmF1y1E909jtPVA1+5uvJN6jPqnzgDZxnymE=; b=IBtIrwtIqjTATg4FGocoebW8A/vB6q/LyTNP3KeE9ZpBKyBMqWDLUqg5/wPztpxHL4 q+BKGQG12mQnN4HgTtJbYIk9rLKpmJh7tFopSsoqC0rCzuM++MqGHp9cnIYnCiBYXs/j 8m4DdXenmOLRG3pGPoJiLIYIxq5sH7bzl08jkhr3i6cYHD/x0m/lIGI8tt7g2WEM6e+E cMTy9fpDIznd1AQah+8f9GZpi61zjigMJ+sBCA9hR/4sHFsURTu1vvoTBnM74GNeSQJf +SfyDctDT+gVZF46MvGcRM6TytPHNQ1ijMcoUewtVSFXUfoJ3kDJIni74M5V6u5xpkJk iDWQ== X-Received: by 10.50.112.4 with SMTP id im4mr20664145igb.1.1372767783964; Tue, 02 Jul 2013 05:23:03 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id kj5sm18104323igb.7.2013.07.02.05.23.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 05:23:02 -0700 (PDT) Message-ID: <51D2C622.7040306@hookflash.com> Date: Tue, 02 Jul 2013 08:22:58 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Tim Panton References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C3098BA@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080109050809070304050709" X-Gm-Message-State: ALoCoQl5Yx8pLlM3Ctu2FiQMkdNpBkmB53rC0iJiRJR4evcFQo7Y3BKp3cj89Z0Va+DOg97L0+Mg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:23:09 -0000 This is a multi-part message in MIME format. --------------080109050809070304050709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit You are absolutely, there are a lot of details. But splitting the details into logical separate components reduces the overall complexity greatly. Plus many of those details are only needed because of a lack ability to properly describe the concept of "streams" at the lower level RTP layer (which really only supports tracks at best, and lacks sufficient details to coordinate any information between them to reassembly remotely as a "stream"). So we are left in a situation where the high layers must coordinate a lot of information to be capable of reassembling the streams when they really should be just negotiating the capabilities of the RTP layer itself. For example, the only thing that should be needed is a flag that says FEC is available in the signaling for the the RTP layer. If it is set then that would imply the engine supports this feature and thus FEC streams may be created by the sending party. Alas, because RTP lacks sufficient depth for such concepts like FEC, you have to signal it. RTP doesn't even have enough information to reassemble tracks into stream, let allow do things like FEC between them. Having said that, by making a scoped object that understands there is some definition of what a stream means needs to be describes, but perhaps that the "future' may not require such crazy definitions like all the stream/ssrc/track mappings, it allows for a short/long-term temporary situation where stream definitions are passed until we are able move to a model where that is no longer needed. When a theoretical next-gen RTP transport is capable of sending entire streams and reassembling them without explicit signaling from an upper layer, we can stop defining all that mapping stuff in signaling and remove that complexity. Basically, it's about scoping the objects, and limiting the requirements needed to exchange per object, and defining exactly what is expected/required in those definitions and allowing for future alternative objects that could replace current ones (if they should become available). The other important aspect is removing the definition how this information must be coordinated and exchanged to allow for a variety of signaling scenarios and alternative state machines. And keeping it relatively simple is important for the simple use cases too so the burden is low. We are well on our way to producing such a draft in short order that does exactly that. All we ask is that people keep an open mind. We have no desire to prevent SDP or offer/answer, just not mandate its usage as an API model. Make sense? -Robin > Tim Panton > 2 July, 2013 4:31 AM > > On 2 Jul 2013, at 08:21, Stefan Håkansson LK wrote: > > Conversely we shouldn't underestimate (again) the difficulty of > describing all the > nitty gritty details in SDP. > > I have the sense that we may have pushed the flexibility of SDP beyond > it's elastic limit. > > I think that over the last year we have discovered that a dynamically > programmable browser > is a fundamentally different beast from a deskphone and that what > suits one may well not suit the other. > > Tim. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --------------080109050809070304050709 Content-Type: multipart/related; boundary="------------020401080106010102030108" --------------020401080106010102030108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
You are absolutely, there are  a lot of details. But splitting the details into logical separate components reduces the overall complexity greatly. Plus many of those details are only needed because of a lack ability to properly describe the concept of "streams" at the lower level RTP layer (which really only supports tracks at best, and lacks sufficient details to coordinate any information between them to reassembly remotely as a "stream"). So we are left in a situation where the high layers must coordinate a lot of information to be capable of reassembling the streams when they really should be just negotiating the capabilities of the RTP layer itself.

For example, the only thing that should be needed is a flag that says FEC is available in the signaling for the the RTP layer. If it is set then that would imply the engine supports this feature and thus FEC streams may be created by the sending party. Alas, because RTP lacks sufficient depth for such concepts like FEC, you have to signal it. RTP doesn't even have enough information to reassemble tracks into stream, let allow do things like FEC between them.

Having said that, by making a scoped object that understands there is some definition of what a stream means needs to be describes, but perhaps that the "future' may not require such crazy definitions like all the stream/ssrc/track mappings, it allows for a short/long-term temporary situation where stream definitions are passed until we are able move to a model where that is no longer needed. When a theoretical next-gen RTP transport is capable of sending entire streams and reassembling them without explicit signaling from an upper layer, we can stop defining all that mapping stuff in signaling and remove that complexity.

Basically, it's about scoping the objects, and limiting the requirements needed to exchange per object, and defining exactly what is expected/required in those definitions and allowing for future alternative objects that could replace current ones (if they should become available). The other important aspect is removing the definition how this information must be coordinated and exchanged to allow for a variety of signaling scenarios and alternative state machines. And keeping it relatively simple is important for the simple use cases too so the burden is low. We are well on our way to producing such a draft in short order that does exactly that.

All we ask is that people keep an open mind. We have no desire to prevent SDP or offer/answer, just not mandate its usage as an API model.

Make sense?

-Robin

2 July, 2013 4:31 AM

On 2 Jul 2013, at 08:21, Stefan Håkansson LK wrote:

Conversely we shouldn't underestimate (again) the difficulty of describing all the
nitty gritty details in SDP. 

I have the sense that we may have pushed the flexibility of SDP beyond it's elastic limit.

I think that over the last year we have discovered that a dynamically programmable browser
is a fundamentally different beast from a deskphone and that what suits one may well not suit the other.

Tim.

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

--------------020401080106010102030108 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD5aT/hKfiF4sTU9SW2vrjVLe3vby9vbGCe eWV4oyxLvGScs3AzgDgAAAVyO9zpg4tpH158JP2dNIZZbKWKK2ttXshaagi2FqouEJBKsBGM rkA49qzaSPXo4WM7KS3PBPjz8I9R+FXxhtNH8K6PZvo/lW96biKygjlhAmCuyusYdCDtIZWy CQQRTpyctDix9FYSajfRnlv/AA2R+01/0VLW/wDvmH/43XRaRwc8T0bwFPpMFzoF3paahcST w2kGwSIw2BEBb7vIG3scjNa1YUqaavqZ0PaVJp20uff/AIV1GXT9LS3vLdYABgSD7xA7HPQ9 uOteNKe597DkhFN9D51+PGmadqvjqwgi0OSJDHI5uReHfNEzodjAhicFAQeMZxXdgoe65s+Y z+pTcoRS13Pjb/hDtD/6At//AN/z/wDE112XY8O3mfpH4I+FEY8L6JLpng+RrhdPFq4trP8A epPCijacgANuBz0wevSrdnuKMpwacWeh33w/8Xal4MvvD+rW+zWb9mOnJYSgSMrR7t4bnYEw QWPfsSQK4ZYf3tD3KWZv2TjPdHn1r8DNTuvD0ep6/wCHb6w1C3TDzThRPCQjSMrTEAyJuX7z ZGOeDxSpYeFGo6ivr0u7fdseXVqzrq0vvtqfHf8Awq/4lf8AQl+IP/ACb/4iu3mRz8rPrX49 f8lh8R/9fp/9ErQanmtp/wAhof8AXlH/AOhNU9WUtkdP4Q/5G/Qv+wha/wDoYoe4H6CUgP/Z --------------020401080106010102030108-- --------------080109050809070304050709-- From palmarti@cisco.com Tue Jul 2 05:50:08 2013 Return-Path: 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 E4AF921F8495 for ; Tue, 2 Jul 2013 05:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.734 X-Spam-Level: X-Spam-Status: No, score=-9.734 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 jMzcjAaWAhLu for ; Tue, 2 Jul 2013 05:50:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E904921F864D for ; Tue, 2 Jul 2013 05:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2056; q=dns/txt; s=iport; t=1372769404; x=1373979004; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Aj0O+4QhhqyqzXq7M7lFVjxH1VCUVmF3gSAjYxzR9UM=; b=Y07tQQ8RYUljVgWIylkmtHElK86eF3yC9xPahy4DsMOly36q3sebdrC3 8n8Z9eu/MyD7Cfujvh/eBnJN6u5QeiOX2dYocGhQGK3qa/6SsBMzdQSt9 M4jsMxZq4Lklik32es4mpIWuxKFhWQlO4xBlguUEuRJRujHiixqMDVjGs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAI/K0lGtJV2Y/2dsb2JhbABagwkySb9NgQAWdIIjAQEBAwF3FAEqVicEGwGIAAYMmz2gNI8pgzxnA4hrkAeQHIMRgig X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208";a="229912226" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 02 Jul 2013 12:50:03 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r62Co3Fd016602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Jul 2013 12:50:03 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 07:50:02 -0500 From: "Pal Martinsen (palmarti)" To: "rtcweb@ietf.org" Thread-Topic: New Version Notification for draft-martinsen-mmusic-malice-00.txt Thread-Index: AQHOdyKrDJEdIB9nBEaog3dG1Z0yug== Date: Tue, 2 Jul 2013 12:50:02 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB1142B651@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.160.14] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] New Version Notification for draft-martinsen-mmusic-malice-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:50:09 -0000 Hi, We submitted a new draft called MALICE today. It is all about smarter appli= cation/network communication. Se abstract for some details. Read the whole = draft to get a lot more details. >=20 > A new version of I-D, draft-martinsen-mmusic-malice-00.txt > has been successfully submitted by Reinaldo Penno and posted to the > IETF repository. >=20 > Filename: draft-martinsen-mmusic-malice > Revision: 00 > Title: Meta-data Attribute signaLling with ICE > Creation date: 2013-07-02 > Group: Individual Submission > Number of pages: 33 > URL: http://www.ietf.org/internet-drafts/draft-martinsen-mmus= ic-malice-00.txt > Status: http://datatracker.ietf.org/doc/draft-martinsen-mmusic-m= alice > Htmlized: http://tools.ietf.org/html/draft-martinsen-mmusic-malice= -00 >=20 >=20 > Abstract: > It can be useful for applications to provide flow metadata > information to on-path devices to influence flow treatment in the > network. Provided that the network is able to provide useful > feedback, this can also influence path selection if an application > have multiple flow paths to choose from. >=20 > This draft describes how this can be achieved by adding metadata to > the STUN packets sent during the ICE connectivity checks or a > slightly modified version of the keep-alive mechanism. Devices on > the media path can use the metadata information to prioritize the > flow, perform traffic engineering, or provide network analytics and > notifications as requested by the endpoints. On-path devices can > append or modify the existing metadata information in the STUN/ICE > messages to enable feedback to other on-path devices or the > applications in both ends of the media session. >=20 > This document describes a framework mechanism for how such metadata > can be transported by STUN when ICE is in use and it covers the > endpoint and on path device processing. The functionality described > here is referred to as MALICE. .-. P=E5l-Erik= From jmillan@aliax.net Tue Jul 2 09:04:07 2013 Return-Path: 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 4D61021F9371 for ; Tue, 2 Jul 2013 09:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 EMlL37CwyKwM for ; Tue, 2 Jul 2013 09:04:02 -0700 (PDT) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id F007521F9F7C for ; Tue, 2 Jul 2013 09:04:01 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w15so4704149vbf.21 for ; Tue, 02 Jul 2013 09:04:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=Qw4JOEPDZEjLD1tXZjrSPW3LoiU9FX46WwqDu7kujOA=; b=V+BAxOyXIOMilz4CICubhR+m1FUzchDrso15oD92DlzOVk9hkc8ygiLbg7T4bnJjh5 iZzqyr9/CcY5Ttb+AJ302ob9N5owfT/MN/V2oMPmQzML1qzSkw8ft0yT0H6mOuzUxHFH fxlOYLUStycupVURNnt/QHRLJjMw1zq7VN7cHdoVWqz8r1TvdePLfpWnA2v3TioMLCsn BCIs+4vUaMjdOggScuozSodNNrMpGrewGKCNfsYlKLkClmWsBRvk/elz/doIPcVH7Vag 3t7ioU5OPzNtZZ4iHTjLvXh3hkJQonex2dOUeLXCFPrDKQFRtV2tAKztsKS/lsFQ4FvT JMlA== MIME-Version: 1.0 X-Received: by 10.220.5.137 with SMTP id 9mr11463601vcv.58.1372781040190; Tue, 02 Jul 2013 09:04:00 -0700 (PDT) Received: by 10.220.49.138 with HTTP; Tue, 2 Jul 2013 09:04:00 -0700 (PDT) Date: Tue, 2 Jul 2013 18:04:00 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: "" Content-Type: multipart/alternative; boundary=001a11c3e45241576e04e0897e0b X-Gm-Message-State: ALoCoQkgQLrTpWQBOVuADu8zn3mtM9ZpaNs8rr3B7RLoI9ZXqgrw3H5SLwXhNjjfNsJNW1+UYUeX Subject: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:04:07 -0000 --001a11c3e45241576e04e0897e0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Please, let me know how this normal use case could be solved with the current API. Alice and Bob have accessed to a Web page offering a basic WebRTC application that they use to speak and see each other. They are in the middle of a media session right now. Alice presses the "Video" button in her web application. A SDP offer with video description is sent to Bob: Bob doesn't want to see her, so his web application rejects the media by using any valid method for that: -- a=3Dinactive -- m=3Dvideo 0 Alice web application received a SDP answer which was consumed successfully by the RTCPeerConnection. Alice thinks she is sharing her video, but she is not. The application "Video" button is disabled since the video is already being shared (theoretically) The application "self-Video" HTML5 video element displays Alice's face. She thinks that Bob is seeing her face too, but he did indeed rejected so. I hope this common scenario can be achieved somehow with the current API. I can't find how to do it though. Thanks in advance --=20 Jos=C3=A9 Luis Mill=C3=A1n --001a11c3e45241576e04e0897e0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please, let me know how this normal= use case could be solved with the current API.

Alice and Bob have accessed to a Web page offering a basic WebRTC appli= cation =C2=A0 that they use to speak and see each other. They are in the mi= ddle of a media session right now.

Alice presses the "Video" button in her= web application. A SDP offer with video description is sent to Bob:
<= div style>
Bob doesn't want to see her, so his web = application rejects the media by using any valid method for that:
-- a=3Dinactive
-- m=3Dvideo 0
<= br>
Alice web application received a SDP answer which was c= onsumed successfully by the RTCPeerConnection. Alice thinks she is sharing = her video, but she is not.

The application "Video" button is= disabled since the video is already being shared (theoretically)

The application "self-Video" HTML5 vi= deo element displays Alice's face. She thinks that Bob is seeing her fa= ce too, but he did indeed rejected so.

I hope this common scenario can be achieved someh= ow with the current API. I can't find how to do it though.
Thanks in advance

--
Jos= =C3=A9 Luis Mill=C3=A1n
--001a11c3e45241576e04e0897e0b-- From enrico.marocco@telecomitalia.it Tue Jul 2 09:14:06 2013 Return-Path: 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 3552121F9246 for ; Tue, 2 Jul 2013 09:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.119 X-Spam-Level: X-Spam-Status: No, score=-101.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Hs3xhzTqCiDP for ; Tue, 2 Jul 2013 09:14:00 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id EBBCD11E80D1 for ; Tue, 2 Jul 2013 09:13:52 -0700 (PDT) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 2 Jul 2013 18:13:50 +0200 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 2 Jul 2013 18:13:49 +0200 Message-ID: <51D2FC3C.8090609@telecomitalia.it> Date: Tue, 2 Jul 2013 18:13:48 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050206070807070301050200" X-TI-Disclaimer: Disclaimer1 Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:14:06 -0000 --------------ms050206070807070301050200 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/2/13 6:04 PM, Jos=C3=A9 Luis Mill=C3=A1n wrote: > Hi, >=20 > Please, let me know how this normal use case could be solved with the > current API. Just off the top of my head: Audio-only call establishment: A --{"action":"CALL","sdp":"v=3D0..."}-> B B --{"action":"ACCEPT CALL","sdp":"v=3D0..."}-> A Rejected audio+video upgrade proposal: A --{"action":"UPGRADE","sdp":"v=3D0..."}-> B B --{"action":"REJECT UPGRADE"}-> A Alice rolls back and removes local video display. I may be missing something, but doesn't look like rocket science to me...= Enrico --------------ms050206070807070301050200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MDIx NjEzNDhaMCMGCSqGSIb3DQEJBDEWBBQxgL+9UCMUAzdgusXDD1fq4VTD9TBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAEsSYyskb9o9Yt6yMSVr49xd5/+EdA5CaNKbsfd4j mV/pFuihWz07e1xihvhRpC3MeJeRfxWuqXy7HTPmOQzwH2fqFpG/IGT997svF3akJQyzrKYr zHClvh2dV+wyOhGYyQREPytu0KdUBirFfE73lwnZ4+oLLswYHXGVcSr5k75dRxGUraiNhAD1 dQHGAXXdYvNXz1iOZ1/kW881uzMm0qbNBRo9cZN02g5PV3TcQhsqEkjRNkVmb92BEbrT4+zI 7lD6L1UZfpvM8JMlRhl/IVsZPKy1ghm0WuDf3MYJ12ImHaFAGPWrCkIPR/8gJyRUYK/1uQB8 xKeQGs+EWg2U0QAAAAAAAA== --------------ms050206070807070301050200-- From jmillan@aliax.net Tue Jul 2 09:30:21 2013 Return-Path: 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 6C13421F9C3E for ; Tue, 2 Jul 2013 09:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 0ltMf2DeigMi for ; Tue, 2 Jul 2013 09:30:17 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1F66021F92B7 for ; Tue, 2 Jul 2013 09:30:17 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id jw11so5049031veb.32 for ; Tue, 02 Jul 2013 09:30:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=P34pnMtEV/laWE3QJBsyjv0A4816jR5BwYEFlmwY26k=; b=Mu7emHChDnZgVxQyXd2IdfBb0dhEqBVF8Y2HXD4+z/OYpEw5y+ydzIgr57Je5ovd+B 6BZflstTJznGCvR1rSrTgVdPu7Lg2Qkmr8ZmSyTV2b5pKizs2BlBKplhI0joKNHAziRM MvLi1faBw9WoemEZJaSO/Mhidc6vLFhrH0qU8TT43GmboyN4ThsxnGVyI3kJ4GXyfhXL KT2pocPbP/qPvpyAbK2norAS1NUAHcWK2+8mB+jnga/l/OhcfnD+vJp0uQpmvNDcEquW r3vUnRrn73zNnUt29cbjWRvv9EpdgLjIfg6+vq92/c1oRe+gk9itqs6M01T14o44hzS4 ubGg== MIME-Version: 1.0 X-Received: by 10.220.5.137 with SMTP id 9mr11504258vcv.58.1372782616626; Tue, 02 Jul 2013 09:30:16 -0700 (PDT) Received: by 10.220.49.138 with HTTP; Tue, 2 Jul 2013 09:30:16 -0700 (PDT) In-Reply-To: <51D2FC3C.8090609@telecomitalia.it> References: <51D2FC3C.8090609@telecomitalia.it> Date: Tue, 2 Jul 2013 18:30:16 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: Enrico Marocco Content-Type: multipart/alternative; boundary=001a11c3e45237d28104e089dcd8 X-Gm-Message-State: ALoCoQmItDtYwnztPx9prtZfESpP7LwT5u29IcHodsOtr5vkAPFpJzV69K5AKkbHbTJcOrxR12pe Cc: "" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:30:21 -0000 --001a11c3e45237d28104e089dcd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Enrico, Yes, you are right. I was missing a detail. Now imagine you are not using your own wire protocol but a standard one, where accepting the request doesn't imply accepting or rejecting the SDP offer, since SDP has its own methods to accept or reject the call as commented before. A --{"action":"CALL","sdp":"v=3D0..."}-> B B --{"action":"ACCEPT CALL","sdp":"v=3D0..."}-> A A --{"action":"CALL","sdp":"v=3D0..."}-> B B --{"action":"ACCEPT CALL","sdp":"v=3D0\r\nm=3Dvideo 0..."}-> A 2013/7/2 Enrico Marocco > On 7/2/13 6:04 PM, Jos=C3=A9 Luis Mill=C3=A1n wrote: > > Hi, > > > > Please, let me know how this normal use case could be solved with the > > current API. > > Just off the top of my head: > > Audio-only call establishment: > > A --{"action":"CALL","sdp":"v=3D0..."}-> B > B --{"action":"ACCEPT CALL","sdp":"v=3D0..."}-> A > > Rejected audio+video upgrade proposal: > > A --{"action":"UPGRADE","sdp":"v=3D0..."}-> B > B --{"action":"REJECT UPGRADE"}-> A > > Alice rolls back and removes local video display. > > I may be missing something, but doesn't look like rocket science to me... > > Enrico > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 Jos=C3=A9 Luis Mill=C3=A1n --001a11c3e45237d28104e089dcd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Enrico,

Yes, you are right. I was missing a detail.

Now imagine you are not using your own wire pr= otocol but a standard one, where accepting the request doesn't imply ac= cepting or rejecting the SDP offer, since SDP has its own methods to accept= or reject the call as commented before.

A --{"= action":"CALL","sdp":"v=3D0..."}-> B<= br>B --{"action":"ACCEPT CALL","sdp":"v= =3D0..."}-> A

A --{= "action":"CALL","sdp":"v=3D0..."}-&= gt; B
B --{"action":"ACCEPT CALL","sdp":&q= uot;v=3D0\r\nm=3Dvideo 0..."}-> A



2013/7= /2 Enrico Marocco <enrico.marocco@telecomitalia.it>
On 7/2/13 6:04 PM, Jos=C3=A9 Luis Mill= =C3=A1n wrote:
> Hi,
>
> Please, let me know how this normal use case could be solved with the<= br> > current API.

Just off the top of my head:

Audio-only call establishment:

A --{"action":"CALL","sdp":"v=3D0...&quo= t;}-> B
B --{"action":"ACCEPT CALL","sdp":"v=3D0= ..."}-> A

Rejected audio+video upgrade proposal:

A --{"action":"UPGRADE","sdp":"v=3D0...&= quot;}-> B
B --{"action":"REJECT UPGRADE"}-> A

Alice rolls back and removes local video display.

I may be missing something, but doesn't look like rocket science to me.= ..

Enrico



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




--
Jos=C3= =A9 Luis Mill=C3=A1n
--001a11c3e45237d28104e089dcd8-- From jmillan@aliax.net Tue Jul 2 09:35:12 2013 Return-Path: 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 6064021F9E5A for ; Tue, 2 Jul 2013 09:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 CCUqSA00KfGZ for ; Tue, 2 Jul 2013 09:35:08 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 144B021F9E39 for ; Tue, 2 Jul 2013 09:35:07 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hv10so2889695vcb.22 for ; Tue, 02 Jul 2013 09:35:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=raEfUc/1jfQj5vl3N1MUpgk0ZTuOez03rDUrvwvtHJg=; b=Do4Ro/KucYb8axE13G6n0zeQZ9O0jVJeFmX+4b5kjVUhzpyU2eFCRpzwPaUE3TGjSL VIqyqgIPj+V3PD2qBunFzvOWiJS7wOb3nv0/lf3PvNSdoReCwQBBucWpyNSlVgCx2T1D RANvKGv9m23hN6MqQ2Q/jQNe78QYSZCt6AWmAWxF2wA3MOti569QAWeSmnLt8CjEXBkR nK1iAY1BxVHrPNFnrvmJxxtP6rwPqoXWT+2ikDXLqvLdwhK0wZdw3PJ++L2STEruTxaT /Kh8TkLXhI/xX3kUo8huOKFwWsVKJx0m7oqQ/Kn+EDvddtOI8HVNjKCVHOf9G7xfAgiJ rkyw== MIME-Version: 1.0 X-Received: by 10.58.40.42 with SMTP id u10mr11621241vek.39.1372782901445; Tue, 02 Jul 2013 09:35:01 -0700 (PDT) Received: by 10.220.49.138 with HTTP; Tue, 2 Jul 2013 09:35:01 -0700 (PDT) In-Reply-To: References: <51D2FC3C.8090609@telecomitalia.it> Date: Tue, 2 Jul 2013 18:35:01 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: Enrico Marocco Content-Type: multipart/alternative; boundary=089e0129420c31d49c04e089ed13 X-Gm-Message-State: ALoCoQkqWcJqrrNfyAao8v4CEzUl1Ya6STxJ/LieJaQitaSL6WPdtBYbv2vd+m/HG2oway1BcTGl Cc: "" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:35:12 -0000 --089e0129420c31d49c04e089ed13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2013/7/2 Jos=C3=A9 Luis Mill=C3=A1n > Thanks Enrico, > > Yes, you are right. I was missing a detail. > > Now imagine you are not using your own wire protocol but a standard one, > where accepting the request doesn't imply accepting or rejecting the SDP > offer, since SDP has its own methods to accept or reject the call as > commented before. > I meant 'accept or reject the SDP offer or part of it' where is said 'accept or reject the call' > > A --{"action":"CALL","sdp":"v=3D0..."}-> B > B --{"action":"ACCEPT CALL","sdp":"v=3D0..."}-> A > > A --{"action":"CALL","sdp":"v=3D0..."}-> B > B --{"action":"ACCEPT CALL","sdp":"v=3D0\r\nm=3Dvideo 0..."}-> A > > > > 2013/7/2 Enrico Marocco > >> On 7/2/13 6:04 PM, Jos=C3=A9 Luis Mill=C3=A1n wrote: >> > Hi, >> > >> > Please, let me know how this normal use case could be solved with the >> > current API. >> >> Just off the top of my head: >> >> Audio-only call establishment: >> >> A --{"action":"CALL","sdp":"v=3D0..."}-> B >> B --{"action":"ACCEPT CALL","sdp":"v=3D0..."}-> A >> >> Rejected audio+video upgrade proposal: >> >> A --{"action":"UPGRADE","sdp":"v=3D0..."}-> B >> B --{"action":"REJECT UPGRADE"}-> A >> >> Alice rolls back and removes local video display. >> >> I may be missing something, but doesn't look like rocket science to me..= . >> >> Enrico >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > -- > Jos=C3=A9 Luis Mill=C3=A1n > --=20 Jos=C3=A9 Luis Mill=C3=A1n --089e0129420c31d49c04e089ed13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



2013/7/2 Jos=C3=A9 Luis Mill=C3=A1n <jmillan@aliax.net>
Thanks Enrico,

Yes, you are right. I was missing a detail.

Now imagine you are not using your own wire pr= otocol but a standard one, where accepting the request doesn't imply ac= cepting or rejecting the SDP offer, since SDP has its own methods to accept= or reject the call as commented before.

I meant 'accept or reject = the SDP offer or part of it' =C2=A0where is said 'accept or reject = the call'

A --{"= action":"CALL","sdp":"v=3D0..."}-> B<= br>B --{"action":"ACCEPT CALL","sdp":"v= =3D0..."}-> A

A --{"action":"CALL","sdp"= :"v=3D0..."}-> B
B --{"action":"ACCEPT= CALL","sdp":"v=3D0\r\nm=3Dvideo 0..."}-> A


<= /div>

2013/7/2 Enr= ico Marocco <enrico.marocco@telecomitalia.it><= br>
On 7/2/13 6:04 PM, Jos=C3=A9 L= uis Mill=C3=A1n wrote:
> Hi,
>
> Please, let me know how this normal use case could be solved with the<= br> > current API.

Just off the top of my head:

Audio-only call establishment:

A --{"action":"CALL","sdp":"v=3D0...&quo= t;}-> B
B --{"action":"ACCEPT CALL","sdp":"v=3D0= ..."}-> A

Rejected audio+video upgrade proposal:

A --{"action":"UPGRADE","sdp":"v=3D0...&= quot;}-> B
B --{"action":"REJECT UPGRADE"}-> A

Alice rolls back and removes local video display.

I may be missing something, but doesn't look like rocket science to me.= ..

Enrico



_____________________________________________= __
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


<= br clear=3D"all">

--
Jos=C3=A9 Luis Mill=C3=A1n



--
Jos=C3=A9 Lu= is Mill=C3=A1n --089e0129420c31d49c04e089ed13-- From ibc@aliax.net Tue Jul 2 09:48:08 2013 Return-Path: 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 C6DA221F9C63 for ; Tue, 2 Jul 2013 09:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 yhlarNmYNS9X for ; Tue, 2 Jul 2013 09:48:03 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id AFB0D21F9C61 for ; Tue, 2 Jul 2013 09:48:03 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u12so3802572qcx.26 for ; Tue, 02 Jul 2013 09:48:03 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=fygiDzPDFMvyWz5nMDOMh/Bc11GKXcQYK1pm+WMqkMI=; b=pKwmVyLqZjjr9o0LXfXVC+vZ+RoLxglYKWGjP0hD0fBS03QoJ4zNjxImCmwVPwRB0t oy8oEe3JWLeE4Ya7HyLLuuCF+gztlswkVXQFinaj51SkkNpVqs829KqpM/KW+dktTT/9 jFO27O5JoRUyXHxS7IwWgKeGKFMr4XFtESl8cfsqemtXR/528DgBTBsgANfYwNFT3LMR 4O6VbKLNMUvS/OQSSzpqXvSUKHnauBhslJUTTFOYRRB2GHE4D3yWvy/6dfxfwoG7j71h y+iLcqLX7znx0gRgnn17hX38yh8WpFWHuajWgqa6OSQp0Pg+qukgj0i/zDZ17P58rOhS 2YiQ== X-Received: by 10.224.182.79 with SMTP id cb15mr40652400qab.48.1372783683265; Tue, 02 Jul 2013 09:48:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 2 Jul 2013 09:47:43 -0700 (PDT) In-Reply-To: <51D2FC3C.8090609@telecomitalia.it> References: <51D2FC3C.8090609@telecomitalia.it> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 2 Jul 2013 18:47:43 +0200 Message-ID: To: Enrico Marocco Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlG7sc+jZTFaP16XPZ2fG4Wcy3NK+a+9fDWhfvlw8W+TSYash6tzXPZDYM9I8Bq0Uu6f+zS Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:48:08 -0000 2013/7/2 Enrico Marocco : > Audio-only call establishment: > > A --{"action":"CALL","sdp":"v=3D0..."}-> B > B --{"action":"ACCEPT CALL","sdp":"v=3D0..."}-> A > > Rejected audio+video upgrade proposal: > > A --{"action":"UPGRADE","sdp":"v=3D0..."}-> B > B --{"action":"REJECT UPGRADE"}-> A SDP itself is a media negotiation protocol so SDP (and its WebRTC "API") should provide a way to determine whether the remote has accepted or not our new stream/track. But how? Current API lacks any kind of event for the case in which the remote replies a SDP rejecting our new local strem/track. -- I=C3=B1aki Baz Castillo From jim.barnett@genesyslab.com Tue Jul 2 10:20:22 2013 Return-Path: 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 96AFF21F888F for ; Tue, 2 Jul 2013 10:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Hg3G7hNYF6R9 for ; Tue, 2 Jul 2013 10:20:17 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id 0077C21F9A2E for ; Tue, 2 Jul 2013 10:20:10 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service107-us.mimecast.com; Tue, 02 Jul 2013 13:20:05 -0400 Received: from GENSJZMBX01.msg.int.genesyslab.com ([fe80::c80a:d985:3cca:a5e7]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 10:20:04 -0700 From: Jim Barnett To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Enrico Marocco Thread-Topic: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API Thread-Index: AQHOd0PwQJX9HXzqg0mu/Vpj2CjNXplRmgAg Date: Tue, 2 Jul 2013 17:20:04 +0000 Message-ID: <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> References: <51D2FC3C.8090609@telecomitalia.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.7.220.231] MIME-Version: 1.0 X-MC-Unique: 113070213200504801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 17:20:22 -0000 V2hlbiB0aGUgSlMgY2FsbHMgc2V0UmVtb3RlIHdpdGggdGhlIHJlc3BvbnNlICh3aGljaCByZWpl Y3RzIHRoZSB2aWRlbyksIHRoZSBVQSB3aWxsIGtub3cgdGhhdCB0aGUgdmlkZW8gaGFzIGJlZW4g cmVqZWN0ZWQuICBJcyB0aGUgaWRlYSB0aGF0IHRoZSBVQSB3aWxsIGxldCB0aGUgdXNlciBrbm93 IHZpYSB0aGUgY2hyb21lPyAgRG8gd2UgdGhpbmsgaXQgaXMgdGhlIEpTIGFwcGxpY2F0aW9ucyBq b2IgdG8gbm90aWZ5IHRoZSB1c2VyIG9mIHN1Y2Nlc3MvZmFpbHVyZSwgb3IgdGhlIFVBJ3M/ICBJ IGRvbid0IHJlY2FsbCBhIGRpc2N1c3Npb24gb2YgdGhpcy4NCg0KLSBKaW0NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJw7Fha2kgQmF6IENhc3RpbGxv DQpTZW50OiBUdWVzZGF5LCBKdWx5IDAyLCAyMDEzIDEyOjQ4IFBNDQpUbzogRW5yaWNvIE1hcm9j Y28NCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBCYXNpYyBzY2Vu YXJpbyAnaW1wb3NzaWJsZT8nIHRvIGFjaGlldmUgd2l0aCB0aGUgYWN0dWFsIEFQSQ0KDQoyMDEz LzcvMiBFbnJpY28gTWFyb2NjbyA8ZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdD46DQo+ IEF1ZGlvLW9ubHkgY2FsbCBlc3RhYmxpc2htZW50Og0KPg0KPiBBIC0teyJhY3Rpb24iOiJDQUxM Iiwic2RwIjoidj0wLi4uIn0tPiBCIEIgLS17ImFjdGlvbiI6IkFDQ0VQVCANCj4gQ0FMTCIsInNk cCI6InY9MC4uLiJ9LT4gQQ0KPg0KPiBSZWplY3RlZCBhdWRpbyt2aWRlbyB1cGdyYWRlIHByb3Bv c2FsOg0KPg0KPiBBIC0teyJhY3Rpb24iOiJVUEdSQURFIiwic2RwIjoidj0wLi4uIn0tPiBCIEIg LS17ImFjdGlvbiI6IlJFSkVDVCANCj4gVVBHUkFERSJ9LT4gQQ0KDQoNClNEUCBpdHNlbGYgaXMg YSBtZWRpYSBuZWdvdGlhdGlvbiBwcm90b2NvbCBzbyBTRFAgKGFuZCBpdHMgV2ViUlRDDQoiQVBJ Iikgc2hvdWxkIHByb3ZpZGUgYSB3YXkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIHJlbW90ZSBo YXMgYWNjZXB0ZWQgb3Igbm90IG91ciBuZXcgc3RyZWFtL3RyYWNrLiBCdXQgaG93PyBDdXJyZW50 IEFQSSBsYWNrcyBhbnkga2luZCBvZiBldmVudCBmb3IgdGhlIGNhc2UgaW4gd2hpY2ggdGhlIHJl bW90ZSByZXBsaWVzIGEgU0RQIHJlamVjdGluZyBvdXIgbmV3IGxvY2FsIHN0cmVtL3RyYWNrLg0K DQotLQ0KScOxYWtpIEJheiBDYXN0aWxsbw0KPGliY0BhbGlheC5uZXQ+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0K cnRjd2ViQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYg0K From jmillan@aliax.net Tue Jul 2 11:05:28 2013 Return-Path: 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 60DB621F9BCF for ; Tue, 2 Jul 2013 11:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 RdmlI21a0wp3 for ; Tue, 2 Jul 2013 11:05:24 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1E00521F9BBC for ; Tue, 2 Jul 2013 11:05:24 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz10so5144799veb.36 for ; Tue, 02 Jul 2013 11:05:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pzFOKEc6XivHCEb/hcuqXfLmR1vKIBqnfdg3qaVlWrc=; b=OXSsu2QUgBk1JD7nQBgVpj8u6Kdx1qEobOykk2Rw1jHIoo8A0hrd8yTYVdARvLWVrc 5Oelt3KwTc4DSaFxcNV9lBJbujRLAup0ZYjZxOo90F7dSb1HAh8ta6MI6CoJY4RYudBH N36PKjlYkSY9tyAftEUb1clZc3ICTQmfP2LFPOQinNlj0d5ksAqpTL0vQ9G5Xxmc9BDk ROUG9iwDLTX5W2cRwFXixYuABoqAAc8qdiruG9EQFle0uzplO2Q6dHCPz4PpVNPy3n7S VY892LQwEnhVTc3doI0sXugE/gsffZ0gh+TDZBEFim6r9/73nYeyFysTkyO9txuV9jmA fHAw== MIME-Version: 1.0 X-Received: by 10.52.33.162 with SMTP id s2mr10110384vdi.37.1372788322447; Tue, 02 Jul 2013 11:05:22 -0700 (PDT) Received: by 10.220.49.138 with HTTP; Tue, 2 Jul 2013 11:05:22 -0700 (PDT) In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> References: <51D2FC3C.8090609@telecomitalia.it> <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> Date: Tue, 2 Jul 2013 20:05:22 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: Jim Barnett Content-Type: multipart/alternative; boundary=20cf307d066a4fc81104e08b3049 X-Gm-Message-State: ALoCoQmKXNKjvYUSTp0fUrdWk3CsY7Jkjrz8OYpE3x+Zs06OPQZgds6cyT8XhMPREhvmeI5PWxlZ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:05:28 -0000 --20cf307d066a4fc81104e08b3049 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In order to avoid the exposed circumstance, where a user has to 'suppose' she is sharing her media because there is no way to certainly know, yes, the JS application should be able to, at least, check if a localMediaStream is being transmitted out of the RTCPeerConnection. This would be a simple task if each mediaStream, or mediaStreamTrack had it's own associated (even if logical because of Boundle) transport. In that case, such connectivity status would give the information and much more control over each media element. 2013/7/2 Jim Barnett > When the JS calls setRemote with the response (which rejects the video), > the UA will know that the video has been rejected. Is the idea that the = UA > will let the user know via the chrome? Do we think it is the JS > applications job to notify the user of success/failure, or the UA's? I > don't recall a discussion of this. > > - Jim > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of I=C3=B1aki Baz Castillo > Sent: Tuesday, July 02, 2013 12:48 PM > To: Enrico Marocco > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the > actual API > > 2013/7/2 Enrico Marocco : > > Audio-only call establishment: > > > > A --{"action":"CALL","sdp":"v=3D0..."}-> B B --{"action":"ACCEPT > > CALL","sdp":"v=3D0..."}-> A > > > > Rejected audio+video upgrade proposal: > > > > A --{"action":"UPGRADE","sdp":"v=3D0..."}-> B B --{"action":"REJECT > > UPGRADE"}-> A > > > SDP itself is a media negotiation protocol so SDP (and its WebRTC > "API") should provide a way to determine whether the remote has accepted > or not our new stream/track. But how? Current API lacks any kind of event > for the case in which the remote replies a SDP rejecting our new local > strem/track. > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Jos=C3=A9 Luis Mill=C3=A1n --20cf307d066a4fc81104e08b3049 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In order to avoid the exposed circumstance, where a user h= as to 'suppose' she is sharing her media because there is no way to= certainly know, yes, the JS application should be able to, at least, check= if a localMediaStream is being transmitted out of the RTCPeerConnection.
This would be a simple task if each mediaStream, or me= diaStreamTrack had it's own associated (even if logical because of Boun= dle) transport. In that case, such connectivity status would give the infor= mation and much more control over each media element.


2013/7/= 2 Jim Barnett <Jim.Barnett@genesyslab.com>
When the JS calls setRemote with the response (which rejects the video), th= e UA will know that the video has been rejected. =C2=A0Is the idea that the= UA will let the user know via the chrome? =C2=A0Do we think it is the JS a= pplications job to notify the user of success/failure, or the UA's? =C2= =A0I don't recall a discussion of this.

- Jim

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of I=C3=B1aki Baz Castillo
Sent: Tuesday, July 02, 2013 12:48 PM
To: Enrico Marocco
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with = the actual API

2013/7/2 Enrico Marocco <enrico.marocco@telecomitalia.it>:
> Audio-only call establishment:
>
> A --{"action":"CALL","sdp":"v=3D0..= ."}-> B B --{"action":"ACCEPT
> CALL","sdp":"v=3D0..."}-> A
>
> Rejected audio+video upgrade proposal:
>
> A --{"action":"UPGRADE","sdp":"v=3D= 0..."}-> B B --{"action":"REJECT
> UPGRADE"}-> A


SDP itself is a media negotiation protocol so SDP (and its WebRTC
"API") should provide a way to determine whether the remote has a= ccepted or not our new stream/track. But how? Current API lacks any kind of= event for the case in which the remote replies a SDP rejecting our new loc= al strem/track.

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb



--
= Jos=C3=A9 Luis Mill=C3=A1n
--20cf307d066a4fc81104e08b3049-- From martin.thomson@gmail.com Tue Jul 2 11:05:53 2013 Return-Path: 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 C5A3421F9B0F for ; Tue, 2 Jul 2013 11:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 RKMdlb4ZiDWE for ; Tue, 2 Jul 2013 11:05:53 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDB621F9A3A for ; Tue, 2 Jul 2013 11:05:52 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so4447865wiv.8 for ; Tue, 02 Jul 2013 11:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=G1SaIuSf5SWaYMkWZyj1OtgtwB5dcsbV8B3olNBQxY0=; b=AArRQqQTrosn1sgGQSCrplHRhHrX8LOrWJuGPpcUgredZJvMDL0YQ8ak1+gYA4OPsr ZopBhqP846sZIq8TsBXh6c+G/uHQWIza8wJ2qPJr3C5Svq2S68xZCuDS8fWurER2mEXd Z4dfdIRk0coXlmNzanqm4p6zkYknxal/gwkBeu9gVDW5v/BLHPQrdImL2KFy3IiRi0UT r14rR/Oi4yVjZvvzKY71GIUw6mxy3d59y9g6H2pxziWZXeH6q02g5r2nzp88cjjPJBqX 6QD2vfpKQTT/Icme4v9otuwZ348GSVZ6k1qBNg524UE5x1Vbi7Yp0myakCSQ2aFrvJv4 ICtA== MIME-Version: 1.0 X-Received: by 10.180.36.12 with SMTP id m12mr16274920wij.10.1372788352241; Tue, 02 Jul 2013 11:05:52 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Tue, 2 Jul 2013 11:05:52 -0700 (PDT) In-Reply-To: <51D2FC3C.8090609@telecomitalia.it> References: <51D2FC3C.8090609@telecomitalia.it> Date: Tue, 2 Jul 2013 11:05:52 -0700 Message-ID: From: Martin Thomson To: Enrico Marocco Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:05:53 -0000 On 2 July 2013 09:13, Enrico Marocco wrot= e: > On 7/2/13 6:04 PM, Jos=C3=A9 Luis Mill=C3=A1n wrote: >> Hi, >> >> Please, let me know how this normal use case could be solved with the >> current API. > > Just off the top of my head: > > Audio-only call establishment: > > A --{"action":"CALL","sdp":"v=3D0..."}-> B > B --{"action":"ACCEPT CALL","sdp":"v=3D0..."}-> A > > Rejected audio+video upgrade proposal: > > A --{"action":"UPGRADE","sdp":"v=3D0..."}-> B > B --{"action":"REJECT UPGRADE"}-> A > > Alice rolls back and removes local video display. This is fine for the case that has been proposed, but it doesn't work as well if A and B are initiating a session. In that case, you would need two rounds of negotiation to get the functionality you describe. There are two separate problems here: 1. How do I reject a proposed stream? 2. How do I learn that my proposed stream was rejected? I'm sure that there are controls for this already... Maybe. You could, as Enrico suggests, add streams one-by-one using multiple offer/answer rounds - then you would be able to isolate what was rejected. That doesn't really scale. Note: These questions are only relevant with offer/answer. Choosing not to do offer/answer means that the application is in control, so the question is moot. From martin.thomson@gmail.com Tue Jul 2 11:06:43 2013 Return-Path: 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 2C6F321F9B0F for ; Tue, 2 Jul 2013 11:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 kN0xefHt2qAe for ; Tue, 2 Jul 2013 11:06:42 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8C421F9BD5 for ; Tue, 2 Jul 2013 11:06:42 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so4925150wgh.4 for ; Tue, 02 Jul 2013 11:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wq7By0XpTAExW1c70rTwMKJhForpPIoPtw7iTMbD1wM=; b=jqZd3kFRkgrDm5Kmf14Ce6nPT+XSj7CudYMJTIfZ5vxw19vN3hon5ppFAX40oTejV7 IaCbKq8SD0H+Z4VIgviDgB/gWPvBDZqDKfe8d77HIE6kwqjYTDNag9cfjlUk6QmBWCBS suVm6fDY/t/jNnW76w+SjTdPdHm+F3VNyiVUPpXjQLIAZOB1wq/Jbx8hAqRr5D+gJuL5 /U21yhnHAfWHABPhjjCNfHROHIse6Q1CS2dGzkTGVxNVNCQ2MnP7F//7sbX0+LIEFPfM Kx8xw65miZkgPScjrCIby53FYwrMKBymhMFPMy54Wvsc0fmxGXxLtA0VV14so/17uOw3 vXFA== MIME-Version: 1.0 X-Received: by 10.194.110.6 with SMTP id hw6mr24769281wjb.3.1372788401525; Tue, 02 Jul 2013 11:06:41 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Tue, 2 Jul 2013 11:06:41 -0700 (PDT) In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> References: <51D2FC3C.8090609@telecomitalia.it> <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> Date: Tue, 2 Jul 2013 11:06:41 -0700 Message-ID: From: Martin Thomson To: Jim Barnett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:06:43 -0000 On 2 July 2013 10:20, Jim Barnett wrote: > When the JS calls setRemote with the response (which rejects the video), = the UA will know that the video has been rejected. Is the idea that the UA= will let the user know via the chrome? Do we think it is the JS applicati= ons job to notify the user of success/failure, or the UA's? I don't recall= a discussion of this. Notifications in Chrome aren't sufficient. The application needs to know t= oo. From lorenzo@meetecho.com Tue Jul 2 11:08:02 2013 Return-Path: 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 2919421F9BD5 for ; Tue, 2 Jul 2013 11:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_55=0.6] 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 Ly2qVfTVuh4J for ; Tue, 2 Jul 2013 11:07:57 -0700 (PDT) Received: from smtpdg7.aruba.it (smtpdg3.aruba.it [62.149.158.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6756521F9BF8 for ; Tue, 2 Jul 2013 11:07:57 -0700 (PDT) Received: from rainpc ([79.10.53.156]) by smtpcmd03.ad.aruba.it with bizsmtp id vW7q1l00K3NCyFj01W7qnZ; Tue, 02 Jul 2013 20:07:54 +0200 Date: Tue, 2 Jul 2013 20:07:50 +0200 From: Lorenzo Miniero To: Jim Barnett Message-ID: <20130702200750.73d1e5b9@rainpc> In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> References: <51D2FC3C.8090609@telecomitalia.it> <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:08:02 -0000 On Tue, 2 Jul 2013 17:20:04 +0000 Jim Barnett wrote: > When the JS calls setRemote with the response (which rejects the video), = the UA will know that the video has been rejected. Is the idea that the UA= will let the user know via the chrome? Do we think it is the JS applicati= ons job to notify the user of success/failure, or the UA's? I don't recall= a discussion of this. >=20 > - Jim >=20 I think that success/failure in such a case would be a quite complex thing = to notify, mostly because you'd first have to define/understand what you're= trying to change: are you just trying to add video? are you changing the p= ort? are you muting one direction? what if something was accepted, and some= thing else not? etc. etc. Anyway, I agree with you that the UA knows about that. In the case of Alice= trying to add video and Bob rejecting it, there may be no callback as of n= ow, but the JS application should already have a way to know the video has = been rejected nevertheless. It might just look at the updated MediaStream i= nstance: if nothing changed, video was rejected (unless in case Bob is only= receiving video and not sending it, e.g., because it has no webcam, there = would be no video track as well?). Not saying it's not ugly, or that a call= back isn't needed, but it may work. Lorenzo > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of I=F1aki Baz Castillo > Sent: Tuesday, July 02, 2013 12:48 PM > To: Enrico Marocco > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the ac= tual API >=20 > 2013/7/2 Enrico Marocco : > > Audio-only call establishment: > > > > A --{"action":"CALL","sdp":"v=3D0..."}-> B B --{"action":"ACCEPT=20 > > CALL","sdp":"v=3D0..."}-> A > > > > Rejected audio+video upgrade proposal: > > > > A --{"action":"UPGRADE","sdp":"v=3D0..."}-> B B --{"action":"REJECT=20 > > UPGRADE"}-> A >=20 >=20 > SDP itself is a media negotiation protocol so SDP (and its WebRTC > "API") should provide a way to determine whether the remote has accepted = or not our new stream/track. But how? Current API lacks any kind of event f= or the case in which the remote replies a SDP rejecting our new local strem= /track. >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From lorenzo@meetecho.com Tue Jul 2 11:11:34 2013 Return-Path: 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 E008821F9C0D for ; Tue, 2 Jul 2013 11:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_55=0.6] 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 JwFQYdMeVBYX for ; Tue, 2 Jul 2013 11:11:30 -0700 (PDT) Received: from smtpdg9.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7C721F9C0C for ; Tue, 2 Jul 2013 11:11:29 -0700 (PDT) Received: from rainpc ([79.10.53.156]) by smtpcmd03.ad.aruba.it with bizsmtp id vWBS1l00z3NCyFj01WBTG1; Tue, 02 Jul 2013 20:11:27 +0200 Date: Tue, 2 Jul 2013 20:11:27 +0200 From: Lorenzo Miniero To: Enrico Marocco Message-ID: <20130702201127.08676aef@rainpc> In-Reply-To: <51D2FC3C.8090609@telecomitalia.it> References: <51D2FC3C.8090609@telecomitalia.it> Organization: Meetecho X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:11:35 -0000 On Tue, 2 Jul 2013 18:13:48 +0200 Enrico Marocco wrote: > On 7/2/13 6:04 PM, Jos=E9 Luis Mill=E1n wrote: > > Hi, > >=20 > > Please, let me know how this normal use case could be solved with the > > current API. >=20 > Just off the top of my head: >=20 > Audio-only call establishment: >=20 > A --{"action":"CALL","sdp":"v=3D0..."}-> B > B --{"action":"ACCEPT CALL","sdp":"v=3D0..."}-> A >=20 > Rejected audio+video upgrade proposal: >=20 > A --{"action":"UPGRADE","sdp":"v=3D0..."}-> B > B --{"action":"REJECT UPGRADE"}-> A >=20 > Alice rolls back and removes local video display. >=20 > I may be missing something, but doesn't look like rocket science to me... >=20 > Enrico >=20 >=20 For the same reasons I just wrote in response to Jim's mail, I'm not sure s= ome kind of a REJECT-UPGRADE action would be enough to address such a scena= rio, especially in case, for instance, part of the update attempt was accep= ted and the rest rejected. Considering several different aspects of a sessi= on may be subject to change, such a mechanism should be aware of that. Lorenzo --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From jmillan@aliax.net Tue Jul 2 11:29:09 2013 Return-Path: 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 DC5FC21F9C08 for ; Tue, 2 Jul 2013 11:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 nIQClmhWRX5p for ; Tue, 2 Jul 2013 11:29:04 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 6E46521F9C06 for ; Tue, 2 Jul 2013 11:29:03 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id gf11so3035068vcb.11 for ; Tue, 02 Jul 2013 11:29:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4OGrDGw+z9pT2bqCWSZVsLVgsvLmQXAHdyetVE+GM/Q=; b=AUst1LFMDZXJbbc6DdGplCCFcwGExrycRyE5t6t57FOucitZSd/7k4S1uaO8Ojb5W3 OTHlIDU/7r2VRToPBurusNfnbgqbFMc+kz8aqjIwmYMWrJB70TTpBP3rm60+wUbL3HUp F6VQgZsX/5O26JV2N4yVhxKdpsNCEk4JFar/vmQSo8TIsxWPRs2Bft/t/JRoq7Qj3ckq C5See3Npv/P8Ft4iELSwgE6FX+9UAfn56lwr3dmRo08/FyCrOWJrwNiAUs3ZnNbxjvSh FzVZCL+FKwnBcFqWvdvXK++ewmptDFl88wNHqUDRqoORD7Eo8uoADIuT5OgBjiH+jGhe V5IQ== MIME-Version: 1.0 X-Received: by 10.52.90.194 with SMTP id by2mr6598940vdb.62.1372789742580; Tue, 02 Jul 2013 11:29:02 -0700 (PDT) Received: by 10.220.49.138 with HTTP; Tue, 2 Jul 2013 11:29:02 -0700 (PDT) In-Reply-To: References: <51D2FC3C.8090609@telecomitalia.it> Date: Tue, 2 Jul 2013 20:29:02 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf3071c9a4f54d9704e08b8472 X-Gm-Message-State: ALoCoQllUM4rAXi5qLJ3ouwyWh896xbzreraDCtFToeXhAGmsLErrNT+GEGckqZm5Gp6X5+GnMMa Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:29:09 -0000 --20cf3071c9a4f54d9704e08b8472 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2013/7/2 Martin Thomson > > > This is fine for the case that has been proposed, but it doesn't work > as well if A and B are initiating a session. In that case, you would > need two rounds of negotiation to get the functionality you describe. > > There are two separate problems here: > > 1. How do I reject a proposed stream? > > 2. How do I learn that my proposed stream was rejected? > > I'm sure that there are controls for this already... Maybe. Apart from the statistics API there aren' t, as far as I know. That would solve the exposed issue. > You > could, as Enrico suggests, add streams one-by-one using multiple > offer/answer rounds - then you would be able to isolate what was > rejected. That doesn't really scale. > Note: These questions are only relevant with offer/answer. Choosing > not to do offer/answer means that the application is in control, so > the question is moot. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Jos=C3=A9 Luis Mill=C3=A1n --20cf3071c9a4f54d9704e08b8472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



2013/7/2 Martin Thomson <martin.thomson@gmail.com>

This is fine for the case that has been proposed, but it doesn't = work
as well if A and B are initiating a session. =C2=A0In that case, you would<= br> need two rounds of negotiation to get the functionality you describe.

There are two separate problems here:

1. How do I reject a proposed stream?

2. How do I learn that my proposed stream was rejected?

I'm sure that there are controls for this already... =C2=A0Maybe. =C2= =A0

Apart from the statistics API the= re aren' t, as far as I know. That would solve the exposed issue.
=
=C2=A0
You
could, as Enrico suggests, add streams one-by-one using multiple
offer/answer rounds - then you would be able to isolate what was
rejected. That doesn't really scale.

Note: These questions are only relevant with offer/answer. =C2=A0Choosing not to do offer/answer means that the application is in control, so
the question is moot.
_________________________________________= ______
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb



--
= Jos=C3=A9 Luis Mill=C3=A1n
--20cf3071c9a4f54d9704e08b8472-- From mzanaty@cisco.com Tue Jul 2 12:18:42 2013 Return-Path: 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 3B4A321F9976 for ; Tue, 2 Jul 2013 12:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 oKMowQZHLNhg for ; Tue, 2 Jul 2013 12:18:29 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DDB7311E80D3 for ; Tue, 2 Jul 2013 12:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7988; q=dns/txt; s=iport; t=1372792702; x=1374002302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C6wffEUbZaD+T8BniPGoWacLptE1obDCSK9bo2yWSJ0=; b=Y0o9hl5L4FOT+kJwcWXaL5QwDA6DN2AJt00D1DHcvbLHBrVt8l7iH8Io HoQGtaqybYwbNCGPjtp92/72Gd60mhUh3Yp6b8RMy8Wo3h8xkVfUzzwO+ rV9LXAuGopRk3Wg3fIrvwPxcVwajlDS66MkgvABxoa7NC3L76kUP0RxSG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAKsk01GtJV2d/2dsb2JhbABagwkySb9VgQcWdIIjAQEBAwEBAQFrCwwEAgEIEQQBAQEKHQcnCxQJCAEBBAENBQgBiAAGDLtWjiIGgQEsBQIFBoJ+ZwOIa4sMlReDEYFoCRcg X-IronPort-AV: E=Sophos;i="4.87,982,1363132800"; d="scan'208";a="230115794" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 02 Jul 2013 19:18:21 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r62JILEo014006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jul 2013 19:18:21 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 14:18:20 -0500 From: "Mo Zanaty (mzanaty)" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Saverio Mascolo Thread-Topic: [rtcweb] More H.264 vs VP8 tests Thread-Index: Ac5vQ4bE4hnmu5ERSv6YOg93i7vBVwIE1oNA Date: Tue, 2 Jul 2013 19:18:19 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D48DD57@xmb-rcd-x14.cisco.com> References: <51C96E36.2000907@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B1C308D3B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309A30@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C309A30@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.30.85] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] More H.264 vs VP8 tests X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 19:18:42 -0000 Encoder rate control is achieved primarily using adaptive quantization. H.2= 64 allows the quantization parameter to adapt at each 16x16 macroblock boun= dary. VP8 allows the quantization parameter to adapt at each segment (typic= ally much larger than a macroblock), and only allows 4 segments per frame. = Theoretically, H.264 allows much finer rate control since it allows much fi= ner adaptive quantization. For example, 720p video is 3600 16x16 macroblock= s, so H.264 can adapt 3600 times versus 4 times for VP8. But practically, t= his is not much of an advantage since quantization is rarely adapted more f= requently than a few times per frame. Good (and bad) rate controllers can be achieved using either H.264 or VP8 w= ith almost equal ease. Mo -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Stefan H=E5kansson LK Sent: Tuesday, July 02, 2013 6:16 AM To: Saverio Mascolo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] More H.264 vs VP8 tests On 2013-07-01 19:10, Saverio Mascolo wrote: > an evaluation of how h264 and vp8 are able to match a changing quality > would be interesting Such an evaluation would be very hard to do. The H.264 standard does not=20 specify any encoder behavior, only the decoder is specified. This means=20 that the encoder can be implemented freely, as long as it produces a=20 bitstream compliant to the standard. Specifically, there is no=20 specification in H.264 on how to implement the rate controller. Thus the=20 rate control mechanisms of two different H.264 encoder implementations=20 could react differently to a change in scene complexity. There is a wealth of H.264 implementations on the market today. Some may=20 have implemented a better rate control mechanism than x264, some may=20 have implemented a worse variant. Testing x264 versus the WebM vp8=20 implemenation with rate control turned on may give some information=20 about the relative merits of these two rate control implementations=20 (although the rate control gives rise to so much measurement noise so=20 even that is hard to do) but it says very little about how the H.264=20 standard compares to the vp8 specification in situations where the scene=20 complexity varies. > > > On Sat, Jun 29, 2013 at 3:17 PM, Stefan H=E5kansson LK > > wrote: > > On 6/25/13 12:17 PM, Harald Alvestrand wrote: > > Again - thanks for releasing this openly! > > > > I ran the scripts (with a few tweaks; you run on a system where sh= is > > bash, not dash, for instance), and got the same numbers within > +/- 0.5% > > (probably some binary version skew); > > I re-run the scripts on another computer with another OS today, and I > get exactly the same results as Bo sent out. I noted however that if = the > input clips are not cut at 10s (but used in their entire length) the > results get slightly different, but within +/- 0.5%. Can this be the > reason why you get slightly different numbers? > > > > we may have disagreements on the > > parameters to use, but we agree on the numbers those parameters > produce. > > > > (I have since modified the Google framework to include a script th= at > > pulls in the sources for the needed binaries and compiles them - > if you > > want to make 100% sure people are working from the same sources, > you may > > want to rebase to a newer version of the comparision toolkit.) > > > > On 06/22/2013 03:41 PM, Bo Burman wrote: > >> Hi all, > >> > >> We have had a look at Google's comparison between VP8 and H.264 > constrained baseline that was posted on April 3rd > (http://www.ietf.org/mail-archive/web/rtcweb/current/msg07028.html). > This post contains, as the one mentioned above (and if the > attachments make it to the list), information on the exact tools and > options used for encoding and should thus be repeatable by anyone > interested. > >> > >> As was already stated by others on this list, one major problem > is that Google's test involves the rate control mechanism. Typically > codecs are measured with rate control turned off, since it acts as a > huge noise on the measurement. Instead we propose to compare the > codecs using fixed qp-levels. The qp-level is the quantization > parameter that affects the rate/distortion tradeoff. Comparing using > fixed qp-levels is what has been used when benchmarking HEVC against > H.264 in the JCT-VC standardization, for instance. We are going to > select a codec (essentially bit stream format), not a rate control > mechanism: Once the codec is selected you can choose whatever rate > control mechanism you wish. > >> > >> We used Google's excellent framework as the baseline and changed > the parameter settings in order to make it possible to measure using > fixed qp. We used the same sequences, but limited them to the first > 10 seconds since they varied from 10 seconds to minutes; this also > eased computation time. > >> > >> We used two H.264 encoder implementations: X264, which is an > open-source codec that can operate in everything from real-time to > slow, and JM which is the reference implementation that was used to > develop H.264. JM is very slow but attempts to be very efficient in > terms of bits per quality. The results were as follows: > >> > >> X264 baseline vs VP8: H.264 wins with 1% > >> JM baseline vs VP8: H.264 wins with 4% > >> > >> Running times: > >> X264: 1 hour 3 minutes > >> VP8: 2 hours 0 minutes > >> JM: order of magnitude slower > >> > >> It is interesting to note that the measurements are more stable > in the new test; the variance of the percentages for the sequences > is now around 70, down from around 700 in Google's test of April > 3rd. We believe this is due to the removal of the rate controller, > which acts like noise on the measurements. > >> > >> We also tried setting H.264 to constrained high (no interlace > and no B-pictures, compared to high). The results were then: > >> > >> X264 constrained high vs VP8: H.264 wins with 25% > >> JM constrained high vs VP8: H.264 wins with 24% > >> > >> We also note that the script that Google provided to calculate > the rate differences ("BD-rate") does not give exactly the same > numbers as the JCT-VC-way of calculating BD-rate. The main > difference is that the JM score for constrained high is better > (around 29%) if the JCT-VC way of calculating BD-rate is used. > >> > >> In summary we think that proper testing can conclude that there > is no clear performance advantage to any codec between VP8 and H.264 > baseline. When comparing VP8 against H.264 constrained high on the > other hand, it seems like there is an advantage for H.264 > constrained high. > >> > >> The attached file includes the files necessary to reproduce the > test. > >> > >> Best Regards, > >> > >> Bo Burman > >> > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From enrico.marocco@telecomitalia.it Tue Jul 2 13:12:09 2013 Return-Path: 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 93ACB21F9B21 for ; Tue, 2 Jul 2013 13:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.419 X-Spam-Level: X-Spam-Status: No, score=-101.419 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 J68P9cW7ilqL for ; Tue, 2 Jul 2013 13:11:59 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id A486321F9993 for ; Tue, 2 Jul 2013 13:11:58 -0700 (PDT) Received: from grfhub701rm001.griffon.local (10.19.3.8) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 2 Jul 2013 22:11:54 +0200 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.234) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 2 Jul 2013 22:11:54 +0200 Message-ID: <51D33409.9010906@telecomitalia.it> Date: Tue, 2 Jul 2013 22:11:53 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Martin Thomson References: <51D2FC3C.8090609@telecomitalia.it> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020508030209060907070106" X-TI-Disclaimer: Disclaimer1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 20:12:09 -0000 --------------ms020508030209060907070106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/2/13 8:05 PM, Martin Thomson wrote: > There are two separate problems here: >=20 > 1. How do I reject a proposed stream? >=20 > 2. How do I learn that my proposed stream was rejected? >=20 > I'm sure that there are controls for this already... Maybe. You > could, as Enrico suggests, add streams one-by-one using multiple > offer/answer rounds - then you would be able to isolate what was > rejected. That doesn't really scale. Come on, Martin, what Enrico suggested was one of a probably unlimited number of possible approaches for one very specific supposedly unaddressable use case. It was put together and sent within 9' since the initial email hit the list -- don't build your case on it! FWIW I agree that, in more complex scenarios where streams are frequently added and/or removed, requiring a single O/A for each operation is going to be a problem. My preference -- a reasonable tradeoff at this point in time -- would be to limit SDP O/A to negotiation of ICE params, crypto material and payload types, and do stream manipulation in an app-specific way. The latter is no-plan, that incidentally carries my name on it. The former looks pretty much like plan A. Enrico --------------ms020508030209060907070106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MDIy MDExNTNaMCMGCSqGSIb3DQEJBDEWBBROoEP4auyWpcqBgkVeRsiSqku5rjBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAM5d8vENFu6mpQl2wL1fTny0yMPc49AdGjR2PNyDo 4ct4OGpikQt9EnZi1+pEiVo/UmZvhH3yRUMg8YgDRHHqpdwF34MR6/yLxZurVUbccAwr/8+w 3uL1ww+4JzAuoZJf2kFGqdKyomqEsjhrJ1CyrPM5c13KTjVReFF9917k57I2YkyWiMvOkFmA C/VS1qldMnW0h4Ux1ZJlQvv+6bE3M0uE/+OsPggkghrRdht2iv+6FP/FRchgZqMIVAHAnLOD wikSPFtUMh+717FHvye9hjmSFeSD7SXfdMQ0ETdXlRq1kF09lFTZ1+Wbn6ul/zBjUElB0QIS OeBALkqrmCSc0QAAAAAAAA== --------------ms020508030209060907070106-- From roman@telurix.com Tue Jul 2 14:00:32 2013 Return-Path: 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 E69E011E80F7 for ; Tue, 2 Jul 2013 14:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Gd9U43LZkuy9 for ; Tue, 2 Jul 2013 14:00:27 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4DA11E80E0 for ; Tue, 2 Jul 2013 14:00:25 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so5257182wgh.24 for ; Tue, 02 Jul 2013 14:00:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Ihqb1rKyyKdgcpYzj9eGQ2TBf5sz2linqe4Vg0v2IKc=; b=RNEk14zEc6QFtujo2Ln6Wh7ExFEzySnFmz3a5Et3Eie09WrAjbptWUfsJPa7ltZd1M fm78imTZ99wn5TNcCmUbjRuJiU62txkHur1KRWq4Ej+j0a/SzHbgvDytHotXqGjlFuG0 twqaF82k3Qm1FFljLnALXhK45HDcIFf13VCZrN9cthSVI3EvpBUtF4pAD9IvHeJdQLpl fDTx7wFJCtvXNpjAozkI0f0/GEbH/NgBI27jzfTNPdZlzh+ocDGt470q62rIphanZFIL zXPmOjKmSPKLp1DoZOL5WROKXTuHPXqFyy2tE3lN5/2FDNpylY+J6515U9s3uhMpDYAI qI8A== X-Received: by 10.194.58.11 with SMTP id m11mr25003655wjq.45.1372798825001; Tue, 02 Jul 2013 14:00:25 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [2a00:1450:400c:c00::235]) by mx.google.com with ESMTPSA id ev19sm25257821wid.2.2013.07.02.14.00.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 14:00:23 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so5193202wgg.20 for ; Tue, 02 Jul 2013 14:00:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.173.71 with SMTP id bi7mr24680026wjc.2.1372798822273; Tue, 02 Jul 2013 14:00:22 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Tue, 2 Jul 2013 14:00:22 -0700 (PDT) In-Reply-To: <51D33409.9010906@telecomitalia.it> References: <51D2FC3C.8090609@telecomitalia.it> <51D33409.9010906@telecomitalia.it> Date: Tue, 2 Jul 2013 17:00:22 -0400 Message-ID: From: Roman Shpount To: Enrico Marocco Content-Type: multipart/alternative; boundary=089e0112cf9a265e8104e08da2c3 X-Gm-Message-State: ALoCoQkhxOitH/+oFGLyOlJ4DTB32syLqe8SSZu8HuDA8oHP9Xey+UmZDMMGR5o3WVvs84aRqVCU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 21:00:33 -0000 --089e0112cf9a265e8104e08da2c3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 2, 2013 at 4:11 PM, Enrico Marocco < enrico.marocco@telecomitalia.it> wrote: > > FWIW I agree that, in more complex scenarios where streams are > frequently added and/or removed, requiring a single O/A for each > operation is going to be a problem. My preference -- a reasonable > tradeoff at this point in time -- would be to limit SDP O/A to > negotiation of ICE params, crypto material and payload types, and do > stream manipulation in an app-specific way. The latter is no-plan, that > incidentally carries my name on it. The former looks pretty much like > plan A. > > Since ICE needs to be set via API methods in order to support trickle ICE the only thing that really needs to be in the initial O/A is crypto. Move this into separate API methods and O/A can be gone. _____________ Roman Shpount --089e0112cf9a265e8104e08da2c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 2, 2013 at 4:11 PM, Enrico Marocco <= span dir=3D"ltr"><enrico.marocco@telecomitalia.it> wrote:

FWIW I agree that, in more complex scenarios where streams are
frequently added and/or removed, requiring a single O/A for each
operation is going to be a problem. My preference -- a reasonable
tradeoff at this point in time -- would be to limit SDP O/A to
negotiation of ICE params, crypto material and payload types, and do
stream manipulation in an app-specific way. The latter is no-plan, that
incidentally carries my name on it. The former looks pretty much like
plan A.


Since ICE needs to be set via API methods in order t= o support trickle ICE the only thing that really needs to be in the initial= O/A is crypto. Move this into separate API methods and O/A can be gone.
_____________
Roman Shpount
=A0
--089e0112cf9a265e8104e08da2c3-- From ibc@aliax.net Tue Jul 2 14:16:31 2013 Return-Path: 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 3A31421F901A for ; Tue, 2 Jul 2013 14:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 6Sy5MDh1XTGr for ; Tue, 2 Jul 2013 14:16:24 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7112621F8FDC for ; Tue, 2 Jul 2013 14:16:24 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id w7so2645429qeb.32 for ; Tue, 02 Jul 2013 14:16:23 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=gth39vkm/4uDoyuuMww0kPgT258WGMtUKakVooSGuz8=; b=Seke+WQ2FfN5pJIs3XaBR2tiWgIPv7kJ4Lie72/23NVvQI/81EP29iQw8ovwA0LaZz TaLmv6t7tAmfUiXedYJgBcYXEirEFWkL/Q+3Cl43d2mvc7FA6D2lDu3MlFMVjoz5MipO g0LHTbDPl/AH8RVOn9N4BlDuWRDTW+LypAtbKiyediXs4kDABJSQmCxLWHCA4DvgTb85 yCsp0wglwkAfDjFFSCItfeRNuRnAvPQZQB9Sz2xuw6UMGZKYVVf0Bq+4x4SJhmj+VtFL Dl9QaPnW7vdeIXnYQRz2ooZXFpV9IgEu3d9L1ohh3X7mV0f5MM/fLdYbOkN5nZkEUbrO 6k2A== X-Received: by 10.224.182.79 with SMTP id cb15mr42014235qab.48.1372799783839; Tue, 02 Jul 2013 14:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 2 Jul 2013 14:16:03 -0700 (PDT) In-Reply-To: <20130702200750.73d1e5b9@rainpc> References: <51D2FC3C.8090609@telecomitalia.it> <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> <20130702200750.73d1e5b9@rainpc> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 2 Jul 2013 23:16:03 +0200 Message-ID: To: Lorenzo Miniero Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkq/ixzreeCVQ6qOHcXG0AP99phFwdLwqHV1gkvULILMKKCWZnmsvikKHpGmwg4DafAvMQ9 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 21:16:31 -0000 2013/7/2 Lorenzo Miniero : > Anyway, I agree with you that the UA knows about that. In the case of Ali= ce trying to add video and Bob rejecting it, there may be no callback as of= now, but the JS application should already have a way to know the video ha= s been rejected nevertheless. It might just look at the updated MediaStream= instance: if nothing changed, video was rejected That is *really* ugly, don't you think? -- I=C3=B1aki Baz Castillo From bossiel@yahoo.fr Tue Jul 2 14:36:41 2013 Return-Path: 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 1219911E80E0 for ; Tue, 2 Jul 2013 14:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 s3iQEdyizVxN for ; Tue, 2 Jul 2013 14:36:36 -0700 (PDT) Received: from nm19-vm0.bullet.mail.ird.yahoo.com (nm19-vm0.bullet.mail.ird.yahoo.com [77.238.189.92]) by ietfa.amsl.com (Postfix) with SMTP id 2F4F011E80E6 for ; Tue, 2 Jul 2013 14:36:35 -0700 (PDT) Received: from [77.238.189.54] by nm19.bullet.mail.ird.yahoo.com with NNFMP; 02 Jul 2013 21:36:33 -0000 Received: from [212.82.108.249] by tm7.bullet.mail.ird.yahoo.com with NNFMP; 02 Jul 2013 21:36:33 -0000 Received: from [127.0.0.1] by omp1014.mail.ird.yahoo.com with NNFMP; 02 Jul 2013 21:36:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 468126.15449.bm@omp1014.mail.ird.yahoo.com Received: (qmail 67102 invoked by uid 60001); 2 Jul 2013 21:36:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372800993; bh=e6IsVempR/kZjXpvjbXeivOUkwocGwxWnHbkYOOgrDA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CwPWcCwE+krEk8QstFQ04GZ9V92m0yb2JhFaZbCb2O9sdSn/8b49C7jgbLplyw24LRUYFLKKW9NvlxVG8UtUmQtK3QNzpSgW6JhQTQdlw2diJdeijQJE5se+yWeqIaoV5749rtVxLDmwMIkFl7MCmD7FBS2WsHn7r8SCLxlLeXc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FtiBTWZFVqmPVscAANKFlvEU53QzXeft9hXn5ItBJQj9oRjtT9LHeaHnKoyU765+X0KHxkokGE9WccMXwE928yJDhJXKJGCqCh+xExyyt4sLVRL9zO0zKIPTxLG3tTXpDqIVZgdVzrOa0fsXcewfgsmcXh5p+X1RA+V7iBqbF5s= ; X-YMail-OSG: BHLrxXMVM1lOoOes_Tk6OL7wG.QyfJvwwJ.sCp7dqEAcOk3 p.8_8otd2fE5jIf5XI5qz Received: from [88.179.39.5] by web171301.mail.ir2.yahoo.com via HTTP; Tue, 02 Jul 2013 22:36:32 BST X-Rocket-MIMEInfo: 002.001, WW91IGhhdmUgc2FpZDogIkZvciBleGFtcGxlLCB0aGUgb25seSB0aGluZyB0aGF0IHNob3VsZCBiZSBuZWVkZWQgaXMgYSBmbGFnIHRoYXQgc2F5cyBGRUMgaXMgYXZhaWxhYmxlIGluIHRoZSBzaWduYWxpbmcgZm9yIHRoZSB0aGUgUlRQIGxheWVyLsKgIgoKSSBkb24ndCByZWFsbHkgdGhpbmsgYW5kIHRoaXMgaXMgd2h5IEkgYWxyZWFkeSBzYWlkIHRoZSBqb2IgaXMgTVVDSCBoYXJkZXIgdGhhbiB5b3UgdGhpbmsuCi0gWW91IGFsc28gbmVlZCB0byBzYXkgd2hpY2gga2luZyBvZiBGRUMgeW91IHdhbnQgdG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: <51CA6FEE.6030702@hookflash.com> <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C309655@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30979C@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C3098BA@ESESSMB209.ericsson.se> <51D2C622.7040306@hookflash.com> Message-ID: <1372800992.66449.YahooMailNeo@web171301.mail.ir2.yahoo.com> Date: Tue, 2 Jul 2013 22:36:32 +0100 (BST) From: Bossiel thioriguel To: Robin Raymond , Tim Panton In-Reply-To: <51D2C622.7040306@hookflash.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="862858767-1579880068-1372800992=:66449" Cc: "diopmamadou@doubango.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bossiel thioriguel List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 21:36:41 -0000 --862858767-1579880068-1372800992=:66449 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable You have said: "For example, the only thing that should be needed is a flag= that says FEC is available in the signaling for the the RTP layer.=A0"=0A= =0AI don't really think and this is why I already said the job is MUCH hard= er than you think.=0A- You also need to say which king of FEC you want to u= se. Let's say it's ulpfec (RFC 5109)=0AIf we are using ulpfec:=0AA- It is a= llowed to send FEC packets in the same stream as the protected one or not.= =0AB- When FEC uses different stream then, it is possible to secure it or n= ot regardless the protect stream is secure or not. (e.g SRTP/FEC and RTP/Pr= otected stream). All=A0combinations=A0are possible. When both are encrypted= they even could use different keys (if different channels).=0AC- FEC could= be bundled with RED or not=0AD- When FEC use different channel then, it co= uld use different rate than the protected stream if bundled with RED=0AE- S= ay which media (audio, video, application...) and stream you want to protec= t=0AF-Whether only one level of protection will be used ("onelevelonly" par= ameter)=0AG- etc etc...=0A=0ASDP=A0already=A0allow all these use-cases. Dep= ending on the =A0implementations,=A0signalling=A0[A-F] could be mandatory.= =0A=0AGood luck...=0A=0A=0A________________________________=0A De=A0: Robin= Raymond =0A=C0=A0: Tim Panton = =0ACc=A0: "rtcweb@ietf.org" =0AEnvoy=E9 le : Mardi 2 jui= llet 2013 14h22=0AObjet=A0: Re: [rtcweb] New Draft - WebRTC JS Object API M= odel=0A =0A=0A=0A=0AYou are absolutely, there are=A0 a lot of details. But = splitting the =0Adetails into logical separate components reduces the overa= ll complexity =0Agreatly. Plus many of those details are only needed becaus= e of a lack =0Aability to properly describe the concept of "streams" at the= lower level=0A RTP layer (which really only supports tracks at best, and l= acks =0Asufficient details to coordinate any information between them to = =0Areassembly remotely as a "stream"). So we are left in a situation where = =0Athe high layers must coordinate a lot of information to be capable of = =0Areassembling the streams when they really should be just negotiating the= =0A capabilities of the RTP layer itself.=0A=0AFor example, the only thing = that should be needed is a flag that says =0AFEC is available in the signal= ing for the the RTP layer. If it is set =0Athen that would imply the engine= supports this feature and thus FEC =0Astreams may be created by the sendin= g party. Alas, because RTP lacks =0Asufficient depth for such concepts like= FEC, you have to signal it. RTP =0Adoesn't even have enough information to= reassemble tracks into stream, =0Alet allow do things like FEC between the= m.=0A=0AHaving said that, by making a scoped object that understands there = is =0Asome definition of what a stream means needs to be describes, but =0A= perhaps that the "future' may not require such crazy definitions like =0Aal= l the stream/ssrc/track mappings, it allows for a short/long-term =0Atempor= ary situation where stream definitions are passed until we are =0Aable move= to a model where that is no longer needed. When a theoretical =0Anext-gen = RTP transport is capable of sending entire streams and =0Areassembling them= without explicit signaling from an upper layer, we can=0A stop defining al= l that mapping stuff in signaling and remove that =0Acomplexity.=0A=0ABasic= ally, it's about scoping the objects, and limiting the requirements=0A need= ed to exchange per object, and defining exactly what is =0Aexpected/require= d in those definitions and allowing for future =0Aalternative objects that = could replace current ones (if they should =0Abecome available). The other = important aspect is removing the definition=0A how this information must be= coordinated and exchanged to allow for a =0Avariety of signaling scenarios= and alternative state machines. And =0Akeeping it relatively simple is imp= ortant for the simple use cases too =0Aso the burden is low. We are well on= our way to producing such a draft =0Ain short order that does exactly that= .=0A=0AAll we ask is that people keep an open mind. We have no desire to = =0Aprevent SDP or offer/answer, just not mandate its usage as an API model.= =0A=0AMake sense?=0A=0A-Robin=0A=0A=0ATim Panton=0A>2 July, 2013 4:31 AM=0A= >=0A>=0A>On 2 Jul 2013, at 08:21, Stefan H=E5kansson LK wrote:=0A>=0A>Conve= rsely we =0Ashouldn't underestimate (again) the difficulty of describing al= l the=0A>nitty gritty details in SDP.=A0=0A>=0A>=0A>I have the sense that = =0Awe may have pushed the flexibility of SDP beyond it's elastic limit.=0A>= =0A>=0A>I think that over the last year we have discovered that a dynamical= ly =0Aprogrammable browser=0A>is a fundamentally different beast from a des= kphone and that what suits one may well not suit the other.=0A>=0A>=0A>Tim.= =0A>=0A>=0A>_______________________________________________=0A>rtcweb=0A ma= iling list=0A>rtcweb@ietf.org=0A>https://www.ietf.org/mailman/listinfo/rtcw= eb=0A>=0A>=0A_______________________________________________=0Artcweb maili= ng list=0Artcweb@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/rtcweb --862858767-1579880068-1372800992=:66449 Content-Type: multipart/related; boundary="862858767-249952583-1372800992=:66449" --862858767-249952583-1372800992=:66449 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
= You have said: "For examp= le, the only thing that should be needed is a flag that says FEC is availab= le in the signaling for the the RTP layer. "

I don't really = think and this is why I already said the job is MUCH harder than you think.
<= span style=3D"font-size: 12pt;">- You also need to say which king of FEC yo= u want to use. Let's say it's ulpfec (RFC 5109)
If = we are using ulpfec:
A- It is allowed to send FEC packets = in the same stream as the protected one or not.
B- When FEC uses different stream then, = it is possible to secure it or not regardless the protect stream is secure = or not. (e.g SRTP/FEC and RTP/Protected stream). All combinatio= ns are possible. When both are encrypted they even co= uld use different keys (if different channels).
C- = FEC could be bundled with RED or not
D- When FEC use diffe= rent channel then, it could use different rate than the protected stream if= bundled with RED
E- Say which media (audio, video, application= ...) and stream you want to protect
F-Whether only one lev= el of protection will be used ("onelevelonl= y" parameter)
G- etc etc...

SDP already allow all these use-cases. Depending on the  implementations,&n= bsp;signalling [A-F] could be mandatory.

<= font size=3D"3">Good luck...

=
De : Robin Raymond <robin@hookflash.com>
=C0 : Tim Panton <tim@phonefromhere.com&g= t;
Cc : "rtcweb@i= etf.org" <rtcweb@ietf.org>
Envoy=E9 le : Mardi 2 juillet 2013 14h22
Objet : Re: [rtcweb] New Draft - WebRTC= JS Object API Model

=
=0A =0A

=0AYou are absolutely, there are&= nbsp; a lot of details. But splitting the =0Adetails into logical separate = components reduces the overall complexity =0Agreatly. Plus many of those de= tails are only needed because of a lack =0Aability to properly describe the= concept of "streams" at the lower level=0A RTP layer (which really only su= pports tracks at best, and lacks =0Asufficient details to coordinate any in= formation between them to =0Areassembly remotely as a "stream"). So we are = left in a situation where =0Athe high layers must coordinate a lot of infor= mation to be capable of =0Areassembling the streams when they really should= be just negotiating the=0A capabilities of the RTP layer itself.
=0A=0AFor example, the only thing that should be needed is a flag that says = =0AFEC is available in the signaling for the the RTP layer. If it is set = =0Athen that would imply the engine supports this feature and thus FEC =0As= treams may be created by the sending party. Alas, because RTP lacks =0Asuff= icient depth for such concepts like FEC, you have to signal it. RTP =0Adoes= n't even have enough information to reassemble tracks into stream, =0Alet a= llow do things like FEC between them.
=0A
=0AHaving said that, by mak= ing a scoped object that understands there is =0Asome definition of what a = stream means needs to be describes, but =0Aperhaps that the "future' may no= t require such crazy definitions like =0Aall the stream/ssrc/track mappings= , it allows for a short/long-term =0Atemporary situation where stream defin= itions are passed until we are =0Aable move to a model where that is no lon= ger needed. When a theoretical =0Anext-gen RTP transport is capable of send= ing entire streams and =0Areassembling them without explicit signaling from= an upper layer, we can=0A stop defining all that mapping stuff in signalin= g and remove that =0Acomplexity.
=0A
=0ABasically, it's about scoping= the objects, and limiting the requirements=0A needed to exchange per objec= t, and defining exactly what is =0Aexpected/required in those definitions a= nd allowing for future =0Aalternative objects that could replace current on= es (if they should =0Abecome available). The other important aspect is remo= ving the definition=0A how this information must be coordinated and exchang= ed to allow for a =0Avariety of signaling scenarios and alternative state m= achines. And =0Akeeping it relatively simple is important for the simple us= e cases too =0Aso the burden is low. We are well on our way to producing su= ch a draft =0Ain short order that does exactly that.
=0A
=0AAll we as= k is that people keep an open mind. We have no desire to =0Aprevent SDP or = offer/answer, just not mandate its usage as an API model.
=0A
=0AMake= sense?
=0A
=0A-Robin
=0A
=0A
=0A
=09
=0A =09Tim Panton
=0A 2 July, 2013 4:31=0A AM
=0A

On 2 Jul 2013, at=0A 0= 8:21, Stefan H=E5kansson LK wrote:

Conversely we =0Asho= uldn't underestimate (again) the difficulty of describing all the
nitty=0A gritty details in SDP. 

I have the = sense that =0Awe may have pushed the flexibility of SDP beyond it's elastic= limit.

I=0A think that over the last year we have= discovered that a dynamically =0Aprogrammable browser
is a funda= mentally different beast from a=0A deskphone and that what suits one may we= ll not suit the other.

Tim.

_______________________________________________
rtcweb=0A mailing lis= t
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
=0A
=0A
=0A
=0A

_____________________= __________________________
rtcweb mailing list
rtcweb@ietf.org
http= s://www.ietf.org/mailman/listinfo/rtcweb


--862858767-249952583-1372800992=:66449 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-Id: <1.3919835227@web171301.mail.ir2.yahoo.com> Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD5aT/hKfiF4sTU9SW2vrjVLe3vby9vbGCe eWV4oyxLvGScs3AzgDgAAAVyO9zpg4tpH158JP2dNIZZbKWKK2ttXshaagi2FqouEJBKsBGM rkA49qzaSPXo4WM7KS3PBPjz8I9R+FXxhtNH8K6PZvo/lW96biKygjlhAmCuyusYdCDtIZWy CQQRTpyctDix9FYSajfRnlv/AA2R+01/0VLW/wDvmH/43XRaRwc8T0bwFPpMFzoF3paahcST w2kGwSIw2BEBb7vIG3scjNa1YUqaavqZ0PaVJp20uff/AIV1GXT9LS3vLdYABgSD7xA7HPQ9 uOteNKe597DkhFN9D51+PGmadqvjqwgi0OSJDHI5uReHfNEzodjAhicFAQeMZxXdgoe65s+Y z+pTcoRS13Pjb/hDtD/6At//AN/z/wDE112XY8O3mfpH4I+FEY8L6JLpng+RrhdPFq4trP8A epPCijacgANuBz0wevSrdnuKMpwacWeh33w/8Xal4MvvD+rW+zWb9mOnJYSgSMrR7t4bnYEw QWPfsSQK4ZYf3tD3KWZv2TjPdHn1r8DNTuvD0ep6/wCHb6w1C3TDzThRPCQjSMrTEAyJuX7z ZGOeDxSpYeFGo6ivr0u7fdseXVqzrq0vvtqfHf8Awq/4lf8AQl+IP/ACb/4iu3mRz8rPrX49 f8lh8R/9fp/9ErQanmtp/wAhof8AXlH/AOhNU9WUtkdP4Q/5G/Qv+wha/wDoYoe4H6CUgP/Z --862858767-249952583-1372800992=:66449-- --862858767-1579880068-1372800992=:66449-- From stefan.lk.hakansson@ericsson.com Wed Jul 3 00:30:08 2013 Return-Path: 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 AD03A21F9C87 for ; Wed, 3 Jul 2013 00:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=-1.631, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 iGAw+HBxsr5l for ; Wed, 3 Jul 2013 00:30:03 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3412821F9C83 for ; Wed, 3 Jul 2013 00:30:03 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-22-51d3d2faeafe Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5B.E0.11907.AF2D3D15; Wed, 3 Jul 2013 09:30:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Wed, 3 Jul 2013 09:30:01 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: =?iso-8859-1?Q?Jos=E9_Luis_Mill=E1n?= Thread-Topic: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API Thread-Index: AQHOd06/FDY7Jv7K4kaoB4G5OS/YTA== Date: Wed, 3 Jul 2013 07:30:00 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30A107@ESESSMB209.ericsson.se> References: <51D2FC3C.8090609@telecomitalia.it> <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre6vS5cDDVaskbRoujqNxWLdAROL tf/a2R2YPc41vGf3WPq2g81jyZKfTAHMUVw2Kak5mWWpRfp2CVwZn8//Yyq4IFWxcqJLA+M0 0S5GTg4JAROJhm0TmSBsMYkL99azdTFycQgJHGWUmHu7lxHCWcgosebTITaQKjaBQImt+xYA 2RwcIgK2EpeP+IGEmQWCJSa/hwgLA9mdV3NAwiICIRILjp9ihrD1JK79WMMKYrMIqEg8+7CL BcTmFfCV+P30EjvEqktMEmu3TQNrYAQ66PupNUwQ88Ulbj2ZD3WogMSSPeeZIWxRiZeP/7FC 2EoSPzZcYoGo15O4MXUKG4StLbFs4WtmiGWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG juLU4qTcdCODTYzA6Di45bfFDsbLf20OMUpzsCiJ827ROxMoJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgXHHCnGPi6k2S4Tsvj2YueH6dvYHa4U7zG2/ZfC+qrh0+OAGw5knL88V4+vZdjDe K3u66r4UyVNmv2RCt0zyyitruG/a8NKDTW/qou3/Uzt37lgRdUA0RdeNfWXuTvULym0HHQq0 1UqfqvIukbazPbfLZuZFgRtiZt/zbq9nkp97JlIr5uGbXY+VWIozEg21mIuKEwHnqJZxXAIA AA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 07:30:08 -0000 On 7/2/13 8:05 PM, Jos=E9 Luis Mill=E1n wrote:=0A= > In order to avoid the exposed circumstance, where a user has to=0A= > 'suppose' she is sharing her media because there is no way to certainly= =0A= > know, yes, the JS application should be able to, at least, check if a=0A= > localMediaStream is being transmitted out of the RTCPeerConnection.=0A= =0A= There is a proposal that addresses this:=0A= =0A= http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/att-0005/PrioAPI.= pdf=0A= =0A= (Note that the constraint part would be simplified per the recent =0A= agreements in the Media Capture TF)=0A= =0A= Stefan=0A= =0A= =0A= =0A= >=0A= > This would be a simple task if each mediaStream, or mediaStreamTrack had= =0A= > it's own associated (even if logical because of Boundle) transport. In=0A= > that case, such connectivity status would give the information and much= =0A= > more control over each media element.=0A= >=0A= >=0A= > 2013/7/2 Jim Barnett >=0A= >=0A= > When the JS calls setRemote with the response (which rejects the=0A= > video), the UA will know that the video has been rejected. Is the=0A= > idea that the UA will let the user know via the chrome? Do we think= =0A= > it is the JS applications job to notify the user of success/failure,= =0A= > or the UA's? I don't recall a discussion of this.=0A= >=0A= > - Jim=0A= >=0A= > -----Original Message-----=0A= > From: rtcweb-bounces@ietf.org =0A= > [mailto:rtcweb-bounces@ietf.org ] On= =0A= > Behalf Of I=F1aki Baz Castillo=0A= > Sent: Tuesday, July 02, 2013 12:48 PM=0A= > To: Enrico Marocco=0A= > Cc: rtcweb@ietf.org =0A= > Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with=0A= > the actual API=0A= >=0A= > 2013/7/2 Enrico Marocco >:=0A= > > Audio-only call establishment:=0A= > >=0A= > > A --{"action":"CALL","sdp":"v=3D0..."}-> B B --{"action":"ACCEPT= =0A= > > CALL","sdp":"v=3D0..."}-> A=0A= > >=0A= > > Rejected audio+video upgrade proposal:=0A= > >=0A= > > A --{"action":"UPGRADE","sdp":"v=3D0..."}-> B B --{"action":"REJEC= T=0A= > > UPGRADE"}-> A=0A= >=0A= >=0A= > SDP itself is a media negotiation protocol so SDP (and its WebRTC=0A= > "API") should provide a way to determine whether the remote has=0A= > accepted or not our new stream/track. But how? Current API lacks any= =0A= > kind of event for the case in which the remote replies a SDP=0A= > rejecting our new local strem/track.=0A= >=0A= > --=0A= > I=F1aki Baz Castillo=0A= > >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= >=0A= >=0A= >=0A= > --=0A= > Jos=E9 Luis Mill=E1n=0A= =0A= From stefan.lk.hakansson@ericsson.com Wed Jul 3 00:38:59 2013 Return-Path: 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 12B4111E8176 for ; Wed, 3 Jul 2013 00:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 AEc8X87vvAig for ; Wed, 3 Jul 2013 00:38:52 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 76FC311E8174 for ; Wed, 3 Jul 2013 00:38:52 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-e8-51d3d50bf99b Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8B.22.11907.B05D3D15; Wed, 3 Jul 2013 09:38:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Wed, 3 Jul 2013 09:38:51 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: =?iso-8859-1?Q?Jos=E9_Luis_Mill=E1n?= Thread-Topic: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API Thread-Index: AQHOdz3PRfxdtB3UtEOLGBOa395CpA== Date: Wed, 3 Jul 2013 07:38:50 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30A16F@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvrS731cuBBuePaFusO2BisfZfO7sD k8e5hvfsHkuW/GQKYIrisklJzcksSy3St0vgymhZd5yp4LtAxeqFj5gbGE/zdjFyckgImEi8 /LONCcIWk7hwbz1bFyMXh5DAUUaJP7P+skM4Cxkl3t5bxQ5SxSYQKLF13wKgKg4OEQFbictH /EDCzAKaEhOW7WIDsYUFgiX+TT0NVi4iECLR9ewQC4StJ7Hqz3wwm0VAReLjhblgNbwCvhIv Ts5nBrGFBAIk3qzqBoszAh30/dQaJoj54hK3nsyHOlRAYsme88wQtqjEy8f/WCFsJYnGJU9Y Ier1JG5MncIGYWtLLFv4mhlil6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyipGjOLU4KTfd yGATIzAWDm75bbGD8fJfm0OM0hwsSuK8W/TOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpg 3BW+7UaxxZ6PPxqyFx+I8ZgzJTw1WcaO72sST3CD6mFtsXPi962WCtVLbNh0akqNzuLNCxbx TXz00V+9ozV8+Xo5nhd+E+Y+vRr4ueL5zxl5j2YJ3z5iUqRp8GYD3//YhPciJwrrdj1faHU0 5xS753POD0ov7u48/WnWpcvXzn6bzdGV+3LLNVMlluKMREMt5qLiRACEiw6GUwIAAA== Cc: "" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 07:38:59 -0000 On 7/2/13 6:04 PM, Jos=E9 Luis Mill=E1n wrote:=0A= > Hi,=0A= >=0A= > Please, let me know how this normal use case could be solved with the=0A= > current API.=0A= >=0A= > Alice and Bob have accessed to a Web page offering a basic WebRTC=0A= > application that they use to speak and see each other. They are in the= =0A= > middle of a media session right now.=0A= >=0A= > Alice presses the "Video" button in her web application. A SDP offer=0A= > with video description is sent to Bob:=0A= >=0A= > Bob doesn't want to see her, so his web application rejects the media by= =0A= > using any valid method for that:=0A= > -- a=3Dinactive=0A= > -- m=3Dvideo 0=0A= =0A= My personal view is that even if we use SDP for carrying the association = =0A= between RTP SSRCs and the MediaStream and MediaStreamTrack structures as = =0A= well as negotiating codecs, we should not use it to negotiate what =0A= streams and tracks to use. It should only be used to set up the streams =0A= and tracks over the networks that is decided by the application.=0A= =0A= One way in this specific case could be that Bob's application (since Bob = =0A= does not want to see Alice) simply does not show the video. Bob's =0A= application could in addition signal this to Alice's application (in =0A= some app proprietary way) and Alice's app could remove the video stream =0A= (or track) from PeerConnection to save bandwidth and processing.=0A= =0A= Stefan=0A= =0A= >=0A= > Alice web application received a SDP answer which was consumed=0A= > successfully by the RTCPeerConnection. Alice thinks she is sharing her=0A= > video, but she is not.=0A= >=0A= > The application "Video" button is disabled since the video is already=0A= > being shared (theoretically)=0A= >=0A= > The application "self-Video" HTML5 video element displays Alice's face.= =0A= > She thinks that Bob is seeing her face too, but he did indeed rejected so= .=0A= >=0A= > I hope this common scenario can be achieved somehow with the current=0A= > API. I can't find how to do it though.=0A= >=0A= > Thanks in advance=0A= >=0A= > --=0A= > Jos=E9 Luis Mill=E1n=0A= =0A= From enrico.marocco@telecomitalia.it Wed Jul 3 01:23:40 2013 Return-Path: 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 506F321F9C3E for ; Wed, 3 Jul 2013 01:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.419 X-Spam-Level: X-Spam-Status: No, score=-101.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 NPTbNHwk7FCk for ; Wed, 3 Jul 2013 01:23:32 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0393F21F9C3B for ; Wed, 3 Jul 2013 01:23:27 -0700 (PDT) Received: from grfhub701rm001.griffon.local (10.19.3.8) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 3 Jul 2013 10:23:17 +0200 Received: from MacLab.local (10.229.8.64) by smtp.telecomitalia.it (10.19.9.234) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 3 Jul 2013 10:23:17 +0200 Message-ID: <51D3DF75.1060609@telecomitalia.it> Date: Wed, 3 Jul 2013 10:23:17 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= References: <51D2FC3C.8090609@telecomitalia.it> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090906030002040805000804" X-TI-Disclaimer: Disclaimer1 Cc: "" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 08:23:40 -0000 --------------ms090906030002040805000804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/2/13 6:30 PM, Jos=C3=A9 Luis Mill=C3=A1n wrote: > Thanks Enrico, >=20 > Yes, you are right. I was missing a detail. >=20 > Now imagine you are not using your own wire protocol but a standard one= , > where accepting the request doesn't imply accepting or rejecting the SD= P > offer, since SDP has its own methods to accept or reject the call as > commented before. I assume you are talking about browser-to-browser signalling. If it was a deliberate choice to pick SIP rather than a custom protocol properly designed for the semantics of you application, then it is a self-inflicted pain you cannot blame on the API. If on the other hand you are talking about interworking with SIP networks, I'm sympathetic with you, as there is no way for your gatewaying function (regardless of whether it is on an external element or wired directly into the JS) to avoid SDP parsing and handling of the 42 different ways it defines for signalling stream rejection. My advice in such case: hang on in there! Eventually your customers will be happy to pay you good money for the commendable effort. Enrico --------------ms090906030002040805000804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MDMw ODIzMTdaMCMGCSqGSIb3DQEJBDEWBBQpIjf5Z6jkqskx8OdBpYTNeilXUjBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAqecGg9c1gW9MYfKGyJguxNNRkBTZD077yQ1MpsxV rWVxJf/pexHbXB9CdHDxsgYrSpQ7DTsdttqqVEB9O+7nmsgtdyF3ENPvYUpUipEXY15SA5Dl XuN5gKFHmSoqnf8/bJ2NDJpIwjDCMNR7e77YJ/k2B7frcTRdtSjKu2+Q/QkW0r3H9aU+AF6i hqk5iLf7GhqXsSyExsCJgp4fnM/EldeL/PgyaO7TdTv0Kt5JIpwTV5GqWmX5RtUNOYW4JM01 qoGn3wl0g5YjehZmbs4BGpG+qj9QzIOmbrQZHjd8vndPE+g+B3khRX2H5wGzU2e0JXWYIB70 bSxd3vQ/4kdScAAAAAAAAA== --------------ms090906030002040805000804-- From ibc@aliax.net Wed Jul 3 01:59:18 2013 Return-Path: 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 DF19621F8831 for ; Wed, 3 Jul 2013 01:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 ISdad1bb728X for ; Wed, 3 Jul 2013 01:59:12 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id BF6D621F9CD1 for ; Wed, 3 Jul 2013 01:59:12 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so7099176pbc.11 for ; Wed, 03 Jul 2013 01:59:12 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=CdwEPd8cm6KPX7PH6mhdoAjRSHdxsoBk7F9kx/r6Cf0=; b=b7As9J1XwZYpKa8crwHfHjgpoIgfp+yjkopXOGGoUldu/dvV0fA7lt8B9ffmAD32zl a9pruGmpSbOiRfoPB2zRjxD61SsCRY+nXOqmxZfUNtnH4RbrgHD6pO+rJPU8VtrAtvqW I0G6yghmC9/mOXx+hEiS1VLJx2CMJRCsKeGnhuLldnUnm8JMLdznoEmRLnKC2QrzYp9Y yDO4wcsz5K7EKNlLTeJPaFskFxrDULD9Fclt0vu0rqoVqHqX9RHcGWC+XRB61mNdBZJH L/IEr/15xneUKzGbUsvFEbwiV0ZmSUqm5IDz647dNOkGejW8rln2C9ec+Y0qznnfNzuC JzqQ== X-Received: by 10.66.173.201 with SMTP id bm9mr1532459pac.27.1372841952319; Wed, 03 Jul 2013 01:59:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.74.6 with HTTP; Wed, 3 Jul 2013 01:58:52 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30A16F@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30A16F@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Jul 2013 10:58:52 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmodos/KtJXUmAx/c8uZY6Y8VaUP5CS1nth98vI6f++4l5IN2XzU4pHysZn/I4qFrPU9HRh Cc: "" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 08:59:18 -0000 2013/7/3 Stefan H=C3=A5kansson LK : > One way in this specific case could be that Bob's application (since Bob > does not want to see Alice) simply does not show the video. Bob's > application could in addition signal this to Alice's application (in > some app proprietary way) and Alice's app could remove the video stream > (or track) from PeerConnection to save bandwidth and processing. Let me understand it: So we are forced to use SDP in any WebRTC application but we cannot use SDP for common features (i.e. detecting that the remote peer has rejected our new offered stream/track). Thus regardless we use SDP we cannot do SIP, right? and instead we must use a proprietary signaling mechanism for those so common features already present in SIP and SDP, right? So live with SDP but don't use SDP, am I wrong? So be free to implement any custom signaling protocol (proprietary protocol) but not a standard like SIP since SIP's SDP usage cannot be implemented in WebRTC, right? Opss, I forgot, I can parse my new generated SDP at JS level (the SDP with my new video stream/track offer) and then also parse the received SDP, and detect wheter there is "a=3Dinactive" or "m" line with port 0 to detect that the remote has rejected my stream. Am I really right? Regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Jul 3 04:59:20 2013 Return-Path: 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 6F13C21F94D3 for ; Wed, 3 Jul 2013 04:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 dRJSssh1UOoO for ; Wed, 3 Jul 2013 04:59:15 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 171C521F92E3 for ; Wed, 3 Jul 2013 04:59:14 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so3539859qab.11 for ; Wed, 03 Jul 2013 04:59:14 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=28CS8q1oB5vhE0XzgpI7tQInK3C9biwW/1BORE9eJQg=; b=WUsq8foT6dR24b21DsX0T4yWgN1NrtX2aEo8mEQnG+nBH4W0ahoJXA08hePmDK4fHn qiX9KWvk+kiRKZzf8osz+KyTrCJ32OYj4YlyEsmFzlQZJFgbp0GWZB1nQBDMJfIt4yOl gs1pTD76jOr4Uhl8nTTF6/t62T8ZPwGzf3m4Q+x7lxaEZi9aaSYZDu5NPEKts+cdabY2 ssRwMXxjaSy6yurSllyi6sArfwLOo+SdpJYuPH8oTdtBwua2DZi4sgEa/yLdKoV7DMhj GNoAFXE+YsYf8z1GQdBTXO+QmjjPP70LeZ/lL/i8ZvVPCUW4gXe/x6zKRQjsBSm2VqQQ LqXg== X-Received: by 10.224.59.142 with SMTP id l14mr3252180qah.22.1372852754593; Wed, 03 Jul 2013 04:59:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 3 Jul 2013 04:58:54 -0700 (PDT) In-Reply-To: <20130702200750.73d1e5b9@rainpc> References: <51D2FC3C.8090609@telecomitalia.it> <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> <20130702200750.73d1e5b9@rainpc> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Jul 2013 13:58:54 +0200 Message-ID: To: Lorenzo Miniero Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmaEp8z15Dtxzl77BCJkUKd9IsxJL/0AtwZFFP82CVcXZhdn8eGpnuRIWlukmvRi9ONLCXA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 11:59:20 -0000 2013/7/2 Lorenzo Miniero : > In the case of Alice trying to add video and Bob rejecting it, there may = be no callback as of now, but the JS application should already have a way = to know the video has been rejected nevertheless. It might just look at the= updated MediaStream instance: if nothing changed, video was rejected (unle= ss in case Bob is only receiving video and not sending it, e.g., because it= has no webcam, there would be no video track as well?). One more comment about this: The fact that Alice offers video to Bob does not mean that Bob also should offer video to Alice. It could perfectly occur that Alice offers video to Bob, Bob accepts receiving it but Bob does not send video to Alice (i.e. "a=3Drecvonly"). The problem described in this issue is the fact that Alice has no way to realize whether Bob has accepted receiving her video or not. Bob has replied to the video offer with "m=3Dvideo 0" or "a=3Dinactive", which means that there won't be video RTP from Alice to Bob. But there is no way for Alice's JS to realize of that so Alice's will expect that Bob is receiving her video (when he is not). There is no API callback to know whether the remote has accepted our flows or not. -- I=C3=B1aki Baz Castillo From lorenzo@meetecho.com Wed Jul 3 05:32:10 2013 Return-Path: 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 4065621F9CE1 for ; Wed, 3 Jul 2013 05:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 82HjNMJ7ew2c for ; Wed, 3 Jul 2013 05:32:04 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg4.aruba.it [62.149.158.234]) by ietfa.amsl.com (Postfix) with ESMTP id 099FE21F9CEC for ; Wed, 3 Jul 2013 05:32:03 -0700 (PDT) Received: from lminiero ([143.225.229.175]) by smtpcmd04.ad.aruba.it with bizsmtp id voXz1l00Q3niPy701oXzUl; Wed, 03 Jul 2013 14:32:00 +0200 Date: Wed, 3 Jul 2013 14:31:58 +0200 From: Lorenzo Miniero To: =?UTF-8?B?ScOxYWtp?= Baz Castillo Message-ID: <20130703143158.69136796@lminiero> In-Reply-To: References: <51D2FC3C.8090609@telecomitalia.it> <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com> <20130702200750.73d1e5b9@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 12:32:10 -0000 Il giorno Wed, 3 Jul 2013 13:58:54 +0200 I=C3=B1aki Baz Castillo ha scritto: > 2013/7/2 Lorenzo Miniero : > > In the case of Alice trying to add video and Bob rejecting it, > > there may be no callback as of now, but the JS application should > > already have a way to know the video has been rejected > > nevertheless. It might just look at the updated MediaStream > > instance: if nothing changed, video was rejected (unless in case > > Bob is only receiving video and not sending it, e.g., because it > > has no webcam, there would be no video track as well?). >=20 > One more comment about this: >=20 > The fact that Alice offers video to Bob does not mean that Bob also > should offer video to Alice. It could perfectly occur that Alice > offers video to Bob, Bob accepts receiving it but Bob does not send > video to Alice (i.e. "a=3Drecvonly"). >=20 Yes, that's what I meant by the "unless...": I'm not sure a remote MediaStream would look different in case of no video at all or a recvonly video. If not, I agree that not even the ugly approach I mentioned would work. L. > The problem described in this issue is the fact that Alice has no way > to realize whether Bob has accepted receiving her video or not. Bob > has replied to the video offer with "m=3Dvideo 0" or "a=3Dinactive", which > means that there won't be video RTP from Alice to Bob. But there is no > way for Alice's JS to realize of that so Alice's will expect that Bob > is receiving her video (when he is not). There is no API callback to > know whether the remote has accepted our flows or not. >=20 >=20 > -- > I=C3=B1aki Baz Castillo > From fluffy@cisco.com Wed Jul 3 12:16:41 2013 Return-Path: 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 6255F21F9D4E for ; Wed, 3 Jul 2013 12:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 koG3KDcWJRB0 for ; Wed, 3 Jul 2013 12:16:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B35A921F9D2D for ; Wed, 3 Jul 2013 12:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=768; q=dns/txt; s=iport; t=1372878995; x=1374088595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pfuWdSE7B+ybsq9iJPQlXUVnfCaVyWRP4zFWznsacY0=; b=nCrAmUE+uLOJJpUCZD+TPqJZdqVEK3tvJUgjcH0Xd+oinOs+rtuPe95U EEIYa/x0xmofwUy/gu6ROA9RA87dUbOIc/9d49UboGoM+yCxvRB7IgPQo wWv1kuEkTderSg/w6jcZVF4Sred8ZyLojLD4eCNSY+hdBFjW7dncX171k 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAFh31FGtJV2c/2dsb2JhbABagwl7gkG9doEGFnSCIwEBAQMBeQULAgEIIhkLMiUCBA4FCIgBBroijzgCMQeDBGkDiGugI4FYgTmCKA X-IronPort-AV: E=Sophos;i="4.87,990,1363132800"; d="scan'208";a="230692445" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jul 2013 19:16:35 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r63JGZiI018945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 19:16:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 14:16:34 -0500 From: "Cullen Jennings (fluffy)" To: Robin Raymond Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOdJEmOvnZG+z+f0Kk7cl3DKmS85lNmqUUgAYTtAA= Date: Wed, 3 Jul 2013 19:16:34 +0000 Message-ID: References: <51CFA5D6.201@hookflash.com> In-Reply-To: <51CFA5D6.201@hookflash.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.38] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <762BF7CC9DE853479EFA997B4227CB95@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 19:16:41 -0000 On Jun 29, 2013, at 8:28 PM, Robin Raymond wrote: > Versus this SDP blob that many of us must parse/mangle/generate from our = code if we want to go beyond a basic demo: My assertion has always been we should avoid any JS app needing to touch th= e SDP. Every example I have heard of why people are doing (with exception o= f one) it is ones that there has been discussion of providing an API to do = that and/or to fix a bug in browsers. (Just as FYI, the one exception is Ka= ufrman's use of ICE to put things in what is usual done as a MPLS tunnel. T= here are probably other common ways to solve that problem).=20 I like Peter's idea of trying to capture what are the reason people think t= hey need to look at the SDP.=20 From pthatcher@google.com Wed Jul 3 12:34:45 2013 Return-Path: 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 5BC5B21F9D24 for ; Wed, 3 Jul 2013 12:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 lxTWYc3vWCmj for ; Wed, 3 Jul 2013 12:34:44 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 98FEE21F9B42 for ; Wed, 3 Jul 2013 12:34:44 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id kw10so389391vcb.19 for ; Wed, 03 Jul 2013 12:34:43 -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=XCwtbpE4nr/MfYfnZ1t+7rLCJXCwJfhlZImMP7fGJ7s=; b=bAU2d3eEuMZdYxJVg9zMHBUGDsZcMvSrtqfdVsUOzsaDlG4SXjpb9l6U609byqoq+M ql7Xl4aOOcpTZ4c4nY7IHYrWRKfmDYi4lCV4WyhwFbbUbf+aLypbYJvwRTQKFptwe9UD rLfTbGAlxqsNjFx2izAbCMDVbSu4mg1X75P60Aybzf6/kh3Wo/j6QywVkFDJhN9W7hZ1 dONzu5upBPT0N9LzHgiRNmExysgChowbyCBrWkOkTOrMWiP7i+LJYe2sZYdYagi0kgKs MwsCsymNWc3QO9eSqjVzk5C2oCRb0jzk6E4RRxUHPmdlksJ4wnR4vvI9tJr5TSCGLJvk 9SEg== 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=XCwtbpE4nr/MfYfnZ1t+7rLCJXCwJfhlZImMP7fGJ7s=; b=k8RzvRNIZgqrGmj8Svz/x9NeSFiDG0+dYeijJgZdWEnex+04zIHqrKVYgrfLK7t9Cf VGmqG4ezNWPU0HV7aM51lx1NEtx1+LepXAvxN/8yEI6AZjBsVR3b7isuSQW5Gb2uGPRl oP+d67hkFo5i7aGnP+WEwKCxXNHV/Mf24aEvgnT8glXK0Wk9YYR4ITy32naUJsqmsae7 xm3O6BilWZqRF2VocLATJELVrSvO2hpTPXV8MksS1MlpT91OiTsBaSX6Z35SUljVF8pp /K5EBmbvuAGhElcZ+yDaolTUgRUYGCP+4Zq0HfgDW9FNf2gH2tpHzgY9e2ItJtslvWeB weHg== X-Received: by 10.58.207.195 with SMTP id ly3mr709650vec.77.1372880083848; Wed, 03 Jul 2013 12:34:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.59.71 with HTTP; Wed, 3 Jul 2013 12:34:02 -0700 (PDT) In-Reply-To: References: <51CFA5D6.201@hookflash.com> From: Peter Thatcher Date: Wed, 3 Jul 2013 12:34:02 -0700 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=047d7b6d8d7cb7ac6a04e0a08d4d X-Gm-Message-State: ALoCoQljBXUJmmPckphe5VruCrfpGC9ndIxD/7j2jGyooAdPeCfsstQABhOR8jUFPaA2Yey1rG0mH5AJUxLk7NhIbcC5cSfFS2v92B7Go9FMvea9Xas/ZxaYHX2Q1PHpUkhrTIT2HhKWmazLBTN1XjyMq0i3U4CxwxfqmfCKeXgkfWdvR2wOA0ySVg8HDK+t6jB5NZ8QAN7F Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 19:34:45 -0000 --047d7b6d8d7cb7ac6a04e0a08d4d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We already have some in the spreadsheet that I previously linked ( https://docs.google.com/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdHlZdV9RN0xSWFhy= bVl4anJLRkVPV0E#gid=3D0 ) Wolfgang Beck: Muting a call Lance Stout: Jingle signalling Gustavo Garc=C3=ADa: Set "inactive", control crypto, modifying codecs, modi= fying bitrate, Philipp Hancke: Jingle signalling Alexandre Gouaillard: Knowing the codec list, the tranport details, the bandwidth options, which ice candidates are used or failing Roman Shpount: Interop between browser SDP and MCU SDP Silvia : Not trying to mangle SDP yet, but would like to control bandwidth requests/limitations; bitrate requests; codec settings I=C3=B1aki Baz Castillo: Mangling it, but didn't say for what purpose. And I could give a very long list of things, but I'll continue to keep myself disqualified :). On Wed, Jul 3, 2013 at 12:16 PM, Cullen Jennings (fluffy) wrote: > > On Jun 29, 2013, at 8:28 PM, Robin Raymond wrote: > > > Versus this SDP blob that many of us must parse/mangle/generate from ou= r > code if we want to go beyond a basic demo: > > My assertion has always been we should avoid any JS app needing to touch > the SDP. Every example I have heard of why people are doing (with excepti= on > of one) it is ones that there has been discussion of providing an API to = do > that and/or to fix a bug in browsers. (Just as FYI, the one exception is > Kaufrman's use of ICE to put things in what is usual done as a MPLS tunne= l. > There are probably other common ways to solve that problem). > > I like Peter's idea of trying to capture what are the reason people think > they need to look at the SDP. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b6d8d7cb7ac6a04e0a08d4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We already have some in the spreadsheet that I previously = linked (https://docs.google.com/spreads= heet/ccc?key=3D0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D0)
Wolfgang Beck: Muting a call
Lance Stout: Jingle signalling
Gustavo Garc=C3=ADa: Set "inactive", control cry= pto, modifying codecs, modifying bitrate,
Philipp Hancke: Jingle signalling
Alexandre Gouaillard: Knowing= the codec list, the tranport details, the bandwidth options, which ice can= didates are used or failing
Roman Shpount: Interop betwee= n browser SDP and MCU SDP
Silvia : Not trying to mangle= SDP yet, but would like to control band= width requests/limitations; bitrate requests; codec settings
I=C3=B1aki Baz Castillo: Mangling it, but didn= 9;t say for what purpose.


And I could= give a very long list of things, but I'll continue to keep myself disq= ualified :).




On Wed, Jul 3, 2013 at 12:16 PM, Cu= llen Jennings (fluffy) <fluffy@cisco.com> wrote:

On Jun 29, 2013, at 8:28 PM, Robin Raymond <robin@hookflash.com> wrote:

> Versus this SDP blob that many of us must parse/mangle/generate from o= ur code if we want to go beyond a basic demo:

My assertion has always been we should avoid any JS app needing to to= uch the SDP. Every example I have heard of why people are doing (with excep= tion of one) it is ones that there has been discussion of providing an API = to do that and/or to fix a bug in browsers. (Just as FYI, the one exception= is Kaufrman's use of ICE to put things in what is usual done as a MPLS= tunnel. There are probably other common ways to solve that problem).

I like Peter's idea of trying to capture what are the reason people thi= nk they need to look at the SDP.




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

--047d7b6d8d7cb7ac6a04e0a08d4d-- From fluffy@cisco.com Wed Jul 3 12:49:05 2013 Return-Path: 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 30CBF11E8224 for ; Wed, 3 Jul 2013 12:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 VBgxfDSKOw4y for ; Wed, 3 Jul 2013 12:48:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A478511E821E for ; Wed, 3 Jul 2013 12:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=268; q=dns/txt; s=iport; t=1372880939; x=1374090539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SRRyC8d2LE9JBxet1gx6EhbhMEmP9bdudr6wZ0fUe5M=; b=EoTfoUbZcxd+i8kIAJyJewkHq1LgHRUuQnUDz15Bzs9qgOhwxxtD3X51 orZ9hKvOvXsKycJlId4WkhmTae+BQEuorEYJPSb44IKSBLfGA/9DAr6tb BgxRD9ZvOjDf/Bf7vS0TZUbDJTdsBLJ2hLKF9pKcIq5v59AAVWciBuQno Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAId/1FGtJV2a/2dsb2JhbABagwl7gkG9doEHFnSCIwEBAQMBeQULAgEIDhQZCzIlAgQOBQiIAQa6FI84AjEHgwRpA6kOgViBOYIo X-IronPort-AV: E=Sophos;i="4.87,990,1363132800"; d="scan'208";a="230703347" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jul 2013 19:48:59 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r63Jmxiq026053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 19:48:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 14:48:59 -0500 From: "Cullen Jennings (fluffy)" To: Peter Thatcher Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP) Thread-Index: AQHOdJEmOvnZG+z+f0Kk7cl3DKmS85lNmqUUgAXFAq2AAFe/AA== Date: Wed, 3 Jul 2013 19:48:58 +0000 Message-ID: References: <51CFA5D6.201@hookflash.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.38] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 19:49:05 -0000 On Jul 3, 2013, at 12:34 PM, Peter Thatcher wrote: > And I could give a very long list of things, but I'll continue to keep my= self disqualified :). >=20 >=20 Please bring up the long list now - later just delays the discussion =85 From pthatcher@google.com Wed Jul 3 14:07:13 2013 Return-Path: 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 6116E11E8248 for ; Wed, 3 Jul 2013 14:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 ElQWXa37OD2H for ; Wed, 3 Jul 2013 14:07:12 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3C75911E8247 for ; Wed, 3 Jul 2013 14:07:12 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz10so534498veb.19 for ; Wed, 03 Jul 2013 14:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=yuf63Bt4jgZFGcj7Sl3SvnkRTN8FO09LBgOfTvx02dA=; b=OMAwOB6xHfEAxU+jO3Q6FkVHEtyYeklT4gHbPFwxZ6drqYEOsrEBFrPLQSRT/JC4/m QBrkmKXLDja1SiPpLtw9Kcc6AvB6e0jFnDcU78GAAFyDUesNxzX5pEdwtvb8wOWmGCXQ m4Ic18G5OE4QhUDCJfRvfM4LzXNIlJGnGEmlexEY8n/az/dLBirUFk3Q4zaIpcy27h7r ovh6A2lOQIDM1ReLIg+8skGvFHlWD3Zp+9DiNet6y8d2yl34iSk37m2yWdPgOZjnOOpI GiIKmzdC6Smy9tq/1TKpaU4iuzT4orQdVgxbPoDtOSCZDVkTsPBX7D3EJpY7R72gcs29 UuvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=yuf63Bt4jgZFGcj7Sl3SvnkRTN8FO09LBgOfTvx02dA=; b=VT11LMqQ+QFBaRaNnnL8861kE3KLfQge3b2dI30gYU6Jh7YmeV5V/xsBIs9XZ0vmLg sbBVHbqRel2OvjwtZEUQtZgQ59yi3+mXvJWWCtZxgcrxH+uBuGQ5OC7xx88EIDZY6nNv G2549buSHhTk8sO3Ytmwk0Dy6KXPYFibgCjCpSadtJdFRq66GaJjRjxMoB31BzMQA9HS UW9tZtiWGYMhOGH6QRv7i0qbwWk4i9y0URy8cw41ywj3KrEQ2wOd9IPGX/FdmWnCHCOp 1yPXX9Tvo0BUyntiHokuAFPPLdmGXxGfxCYQkzj1/4zwRPVLlF7smPriRcr/xulbRzqA ureA== X-Received: by 10.52.158.136 with SMTP id wu8mr740015vdb.33.1372885631513; Wed, 03 Jul 2013 14:07:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.59.71 with HTTP; Wed, 3 Jul 2013 14:06:30 -0700 (PDT) From: Peter Thatcher Date: Wed, 3 Jul 2013 14:06:30 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary=089e0160cb9a625ba004e0a1d8b2 X-Gm-Message-State: ALoCoQnLeiiQZkYsrnosrj7wXKoVjRTtQ4Lc3FgjSd/VJJVv+aqmQmJiMepfOEBdVxVSxCV7Ropv1dOhttqxwIYo8rU6QblVONcA2exI8+QhQXQGknPa2SdrNUVrAv3tmTlSdJF8jfYi9cfRfwf6XJSMna181N6W2Fvo2/hS9PCNNWQEKhwLsdoKRLyP7OtKcIpmBruQiCdQ Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 21:07:13 -0000 --089e0160cb9a625ba004e0a1d8b2 Content-Type: text/plain; charset=UTF-8 After about a week of input, and feedback from 19 developers doing a wide range of things using the WebRTC API, we have some data about their opinion of the current API. *Short answer*: 61% "Good for simple Stuff" 49% "Bad for simple stuff" 6% "Good for advanced stuff" 94% "Bad for advanced stuff" 46% "Good/OK/tolerable for 1.0" 54% "Horrible/intolerable for 1.0" 7% "Good/OK/tolerable long-term" 93% "Need a better API long-term" In general the attitude is *"It's OK for simple stuff but bad for advanced stuff", *and *"We can tolerate it for 1.0, but we need something better for 2.0". *But the majority of the feedback was against it even for the 1.0, so the last one is a bit of a stretch. *Long Answer*: I had to interpret the results a little to fit into these buckets, so if you don't like the interpretation, you're more than welcome to interpret your own results from the raw data: https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=1 There seem to be 4 or 5 different camps: Camp #1: Doing very simple things, doesn't touch the SDP. Everything is fine, except they might have things they want to control but can't. Camp #2: Does somewhat more advanced things, touches the SDP a little, has pain, anticipates more pain, would like something better, but thinks this is OK for 1.0. Camp #3: Is trying advanced things, is touching the SDP a lot, and really feels pain. Wants something better, and might tolerate this API for 1.0, but not for long. Camp #4: Doesn't want SDP or O/A in the API at all. Has a very strong dislike for it. Won't tolerate it, even for 1.0. The IETF and W3C should be embarrassed for even suggesting such a terrible API. It's better to go back to the drawing board (if you think those words are strong, go read the spreadsheet or mailing list!) Oh, and of course, for completeness, we should describe Camp #0, which didn't have any input in this feedback: Camp #0: I've used SDP for years and I'm very comfortable with it. Using SDP as the control surface really helps my use case, which is legacy interop. Defining an API without SDP would be too much work, and probably fail. Look at what happened with SDPng! Supporting all these advanced use cases doesn't seem worth it. If developers are doing that much advanced stuff, they can learn to munge SDP. It isn't that bad. (By the way, I'm not a member of Camp #0, so I may be a little off in my description of it. If any member of Camp #0 would like to adjust that description, please feel free). *Suggested Next Step: Figure out what is needed for WebRTC++* * * As Cullen recently pointed out, we need to get a list of things developers want to be able to control in a future version of the API which could hopefully make developers happier Whether that future API is 1.0, 2.0, or 1.1 is an orthogonal question, but let's call it WebRTC++ for now. Clearly, they want a way to control things without SDP, and perhaps without O/A at all. But what do they want to control? We need a good list. I suggest we reach out more closely to the developers, and use their input to create not only a list of things they want to do, but a WebRTC++ API that fulfills those needs without requiring SDP munging. I think we can do this in parallel with the current API work without detracting from it (from the current work, that is). Certainly there is plenty of energy from people interested in working on it (WebRTC++, that is). Such parallel work would not only better capture the needs of developers, but could also improve the WebRTC (not ++) API by incorporating ideas from it. So far, such activity has been frowned on, perhaps out of fear that it's a threat to the current work. But I think it can be done in a way that doesn't threaten anything, and even learns from and builds on the valuable input we are receiving from developers. The alternative is to ask all these developers to wait an indefinite amount of time and munge SDP like crazy until then, and that seems like a rather poor answer. Therefore, I would support an exploratory effort at a "WebRTC++ API". --089e0160cb9a625ba004e0a1d8b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After about a week of input, and feedback from 19 develope= rs doing a wide range of things using the WebRTC API, we have some data abo= ut their opinion of the current API.

Short answer= :

61%=C2=A0"Good = for simple Stuff"=C2=A0 =C2= =A0 49% "Bad for simple stuff"
=C2=A06%= =C2=A0"Good for advanced = stuff" =C2=A0 =C2=A0 =C2=A094% "Bad for advanced stuff"
46= %=C2=A0"Good/OK/tolerable= for 1.0" =C2=A0 =C2=A054% "Horrible/intolerable for 1.0"
=C2=A07%= =C2=A0"Good/OK/tolerable = long-term" =C2=A093% "Need a better API long-term"=C2=A0


In general the attitude is &quo= t;It's OK for simple stuff but bad for advanced stuff", =C2=A0= and "We can tolerate it for 1.0, but we need something better for 2= .0". =C2=A0But the majority of the feedback was against it even fo= r the 1.0, so the last one is a bit of a stretch.


Long Answer:

=
I had to interpret the results a little to fit into these buckets= , so if you don't like the interpretation, you're more than welcome= to interpret your own results from the raw data: =C2=A0https://docs.google.com/spreadsheet/ccc?key=3D0AuaKXw3SkHM= SdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1


There seem to be 4 or 5 different = camps:

Camp #1: =C2=A0Doing very simple things, do= esn't touch the SDP. =C2=A0Everything is fine, except they might have t= hings they want to control but can't.

Camp #2: =C2=A0Does somewhat more advanced things, touc= hes the SDP a little, has pain, anticipates more pain, would like something= better, but thinks this is OK for 1.0.

Camp #3: = =C2=A0Is trying advanced things, is touching the SDP a lot, and really feel= s pain. =C2=A0Wants something better, and might tolerate this API for 1.0, = but not for long.

Camp #4: =C2=A0Doesn't want SDP or O/A in the API a= t all. =C2=A0Has a very strong dislike for it. =C2=A0Won't tolerate it,= even for 1.0. =C2=A0The IETF and W3C should be embarrassed for even sugges= ting such a terrible API. =C2=A0It's better to go back to the drawing b= oard (if you think those words are strong, go read the spreadsheet or maili= ng list!)

Oh, and of course, for completeness, we should describe= Camp #0, which didn't have any input in this feedback:

<= /div>
Camp #0: =C2=A0I've used SDP for years and I'm very comfo= rtable with it. =C2=A0Using SDP as the control surface really helps my use = case, which is legacy interop. =C2=A0Defining an API without SDP would be t= oo much work, and probably fail. =C2=A0Look at what happened with SDPng! = =C2=A0Supporting all these advanced use cases doesn't seem worth it. = =C2=A0 If developers are doing that much advanced stuff, they can learn to = munge SDP. =C2=A0It isn't that bad.=C2=A0

(By the way, I'm not a member of Camp #0, so I may = be a little off in my description of it. =C2=A0If any member of Camp #0 wou= ld like to adjust that description, please feel free).




Suggested Next Step: Figure= out what is needed for WebRTC++

As Cul= len recently pointed out, we need to get a list of things developers want t= o be able to control in a future version of the API which could hopefully m= ake developers happier Whether that future API is 1.0, 2.0, or 1.1 is an or= thogonal question, but let's call it WebRTC++ for now. =C2=A0 Clearly, = they want a way to control things without SDP, and perhaps without O/A at a= ll. =C2=A0But what do they want to control? =C2=A0We need a good list.

I suggest we reach out more closely to the developers, = and use their input to create not only a list of things they want to do, bu= t a WebRTC++ API that fulfills those needs without requiring SDP munging. = =C2=A0I think we can do this in parallel with the current =C2=A0API work wi= thout detracting from it (from the current work, that is). =C2=A0 =C2=A0Cer= tainly there is plenty of energy from people interested in working on it (W= ebRTC++, that is). =C2=A0Such parallel work would not only better capture t= he needs of developers, but could also improve the WebRTC (not ++) API =C2= =A0by incorporating ideas from it. =C2=A0

So far, such activity has been frowned on, perhaps out = of fear that it's a threat to the current work. =C2=A0But I think it ca= n be done in a way that doesn't threaten anything, and even learns from= and builds on the valuable input we are receiving from developers. =C2=A0T= he alternative is to ask all these developers to wait an indefinite amount = of time and munge SDP like crazy until then, and that seems like a rather p= oor answer. =C2=A0Therefore, I would support an exploratory effort at a &qu= ot;WebRTC++ API".





=

=C2=A0=C2=A0
--089e0160cb9a625ba004e0a1d8b2-- From pthatcher@google.com Wed Jul 3 14:11:09 2013 Return-Path: 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 6BB1F11E8233 for ; Wed, 3 Jul 2013 14:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 9bsMmyO8jLbJ for ; Wed, 3 Jul 2013 14:11:09 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id C240C11E80DC for ; Wed, 3 Jul 2013 14:11:08 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x17so490937vbf.24 for ; Wed, 03 Jul 2013 14:11:08 -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=UZO4wyTBk5wU0Ls6N7V+Zr92EHeKWvk0G5SZWhtqVyA=; b=aogOgDYNNsGl2PFwt7Yvn6QjI+SVFIkOnpFM5gNbMLaHLdTL/pyo13cXQrKSQO/Ee2 6bARPktRJ5pLwAHJvxl0wyExsfHoKH9cU1xyhSPZuRqIg1jm/arMz6UFwPoZDCmDQ9f+ 5i9IYeZE/QjM2lAox0gqwaebbF7w1FAKUjVX658H5/lBVUOttZm3+rKBKfozPXZUmO8f CxSKixrV4L4I4ouNHHeW7qEZ/CaylgC3tLjIqzEp5r0nuiW9HqqiblCHkCDNr5zCAe/e D871B5Jsjbgyj9qgYMgstVCHOzU/RlgbFTRVwcEI23fznwPIehiFLDla6eimUxUx07MX vLnQ== 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=UZO4wyTBk5wU0Ls6N7V+Zr92EHeKWvk0G5SZWhtqVyA=; b=c3Suf1SnY5wuE5oj4p32QQFJxiNxwUJaGbvCkKGEEPm2PYsq+Lrr+Fh+cFmlP990yo k3eyIkxCsWOoJgmnSH+Nzd7XCBRrAicGPi2xt4DJ8mY2WuWOPhHsg7Em0L0k6KroEDVh Fgy0yUpSLhg+xejCnkC5NYo40BiDQzeLQbLmiPmzIPRm+kjhZcBsl05p+VlQO+pmLze5 Q2SEdy+18z/wbWj4MqOwYKMgT8r1PjvnLVtWJ3NrWJgVr5GplVMJCMot4h5oZLnYRj2B px9vU1m3ve3QEWHLqSP1wlj6NTLdbSLTbLV/opZKyCGdd1mqzZT0aG1kSbdspD6lcdXo DKSg== X-Received: by 10.52.91.202 with SMTP id cg10mr713434vdb.85.1372885868221; Wed, 03 Jul 2013 14:11:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.59.71 with HTTP; Wed, 3 Jul 2013 14:10:27 -0700 (PDT) In-Reply-To: References: <51CFA5D6.201@hookflash.com> From: Peter Thatcher Date: Wed, 3 Jul 2013 14:10:27 -0700 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=bcaec5015cf77e374604e0a1e677 X-Gm-Message-State: ALoCoQlFEyPlxcerDbZdhBfajnNkOSaqci+hxT7juJ20DpWX4zNCym3kHtb0UC8yAD3No5/FseDu0O+vY2QvHXbtKnJjbv10sBwcTsNXeP7dyYOAhwgEBhZ6Edlif7XOYjfYx7UXhVgHkHKlci5ZQYpFmDHv7fCR0OQyoGgfMY3rJDzAz2gGjOyR0SyzAheuHF9zjUV4R83b Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 21:11:09 -0000 --bcaec5015cf77e374604e0a1e677 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The more I think about it, the more I think I'll refrain from posting what I need. I don't want to make this API just for myself. I want to make it for all the developers that are currently using it and the those that will use it in the future, so I think we should focus on them first. Perhaps if we use their input and begin incorporating it into the API, I can provide secondary input to refine what we work on, but I'd like the primary input to be from other developers. I don't want to make the mistake of building an API just for myself and leaving the developers suffering because I over-focused on myself. To avoid that, I think I'll focus on them first. On Wed, Jul 3, 2013 at 12:48 PM, Cullen Jennings (fluffy) wrote: > > On Jul 3, 2013, at 12:34 PM, Peter Thatcher wrote: > > > And I could give a very long list of things, but I'll continue to keep > myself disqualified :). > > > > > > Please bring up the long list now - later just delays the discussion =E2= =80=A6 > > --bcaec5015cf77e374604e0a1e677 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The more I think about it, the more I think I'll refra= in from posting what I need. =C2=A0I don't want to make this API just f= or myself. =C2=A0I want to make it for all the developers that are currentl= y using it and the those that will use it in the future, so I think we shou= ld focus on them first. =C2=A0 Perhaps if we use their input and begin inco= rporating it into the API, I can provide secondary input to refine what we = work on, but I'd like the primary input to be from other developers. = =C2=A0

I don't want to make the mistake of building an API just= for myself and leaving the developers suffering because I over-focused on = myself. =C2=A0 To avoid that, I think I'll focus on them first.=C2=A0


On Wed, Jul 3= , 2013 at 12:48 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

On Jul 3, 2013, at 12:34 PM, Peter Thatcher <pthatcher@google.com> wrote:

> And I could give a very long list of things, but I'll continue to = keep myself disqualified :).
>
>

Please bring up the long list now - later just delays the discussion = =E2=80=A6


--bcaec5015cf77e374604e0a1e677-- From ekr@rtfm.com Wed Jul 3 14:21:31 2013 Return-Path: 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 1CE9221F9D3D for ; Wed, 3 Jul 2013 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 zSn0yFE1AmmV for ; Wed, 3 Jul 2013 14:21:25 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 613EF21F9D57 for ; Wed, 3 Jul 2013 14:21:22 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id ih17so3907573qab.12 for ; Wed, 03 Jul 2013 14:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=H+cILg1haMGTNVbPC4EhtldmSns1YCbDX5VV0tZRFLE=; b=DF5FiSTvy9I0hrL7fYlkDKIPkNSfqcgzY4XccvvWiwJwDk39tTmiuPO/17kKVm+byA nglVtV4EzxRn2p7ozTz/fx00BbLcLTC2uyvskGUYDSs0rhpbWJHAqNIyTXsdjSO+TmOd BvFV4dS8t1T6WZ6a5h5gRpyPOJuKwZ2cQ3xss1jNJx1so+lRGitahQHk9xCHZaWhewrw 4MBfWdFTVo8/7hgt9suIEo3VPf2iQRBWG8ptP/N86rCh+DYbB4AL5AcnZBaPi6+2g5Me RzHhz2pLxUuQ5s+yF7DUQoADBKX7q4QxuZaexuf+5wR5arc2p/PwItxwrwwWKP5mmIpa 8MNw== X-Received: by 10.229.111.196 with SMTP id t4mr835905qcp.59.1372886481707; Wed, 03 Jul 2013 14:21:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 3 Jul 2013 14:20:41 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 3 Jul 2013 14:20:41 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=0023544707ac0f40f404e0a20b0f X-Gm-Message-State: ALoCoQkW1i8j+D09ArxZsxU0RB8suKupZ9EKkh9XR9oFYOCkwIzS8tDLzBsAwDId7D58yZjbqh+x Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 21:21:31 -0000 --0023544707ac0f40f404e0a20b0f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher wrote: > Camp #0: I've used SDP for years and I'm very comfortable with it. Using > SDP as the control surface really helps my use case, which is legacy > interop. Defining an API without SDP would be too much work, and probably > fail. Look at what happened with SDPng! Supporting all these advanced use > cases doesn't seem worth it. If developers are doing that much advanced > stuff, they can learn to munge SDP. It isn't that bad. > Hmm... That's not my understanding of the situation at all. Rather, I believe the expectation is that you shouldn't have to modify the SDP but rather there should be API points to cover most of the use cases that people want. This isn't to say that all those API points exist or that they work or whatever. -Ekr --0023544707ac0f40f404e0a20b0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher <ptha= tcher@google.com> wrote:
Camp #0: =A0I've u= sed SDP for years and I'm very comfortable with it. =A0Using SDP as the= control surface really helps my use case, which is legacy interop. =A0Defi= ning an API without SDP would be too much work, and probably fail. =A0Look = at what happened with SDPng! =A0Supporting all these advanced use cases doe= sn't seem worth it. =A0 If developers are doing that much advanced stuf= f, they can learn to munge SDP. =A0It isn't that bad.=A0

Hmm... That's not my understandi= ng of the situation at all.

Rather, I believe the = expectation is that you shouldn't have to modify the
SDP but rather there should be API points to cover most of the use cas= es
that people want. This isn't to say that all those API poi= nts exist or that
they work or whatever.

-Ekr


--0023544707ac0f40f404e0a20b0f-- From pthatcher@google.com Wed Jul 3 14:26:40 2013 Return-Path: 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 CF54C21F9D57 for ; Wed, 3 Jul 2013 14:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 q+014wtlDgPB for ; Wed, 3 Jul 2013 14:26:40 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 17D2021F9C01 for ; Wed, 3 Jul 2013 14:26:39 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz10so538550veb.22 for ; Wed, 03 Jul 2013 14:26:39 -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=ltbre0jK5foPCMT2iHcA/nTPUYDIGbPpQW9Z4pK/LFk=; b=plR2vVS+Z9tUClWZa4GCYiiSjz5hUqtTUykCTYTvWa8TcYf1R/+fYNl8V0L0nLyyVG bTC85fV5SqdQhQmY4YEDcgp33qGc3EPofY54xTzShSSILRIboOMc9dwW7C5qWiMhOtDR rer4qGT1uMsQLyeT+3+hG6UrOOtYHWkLwxqnMEXGeG+jSCKznj3hoJyU4MWZWmseFXn4 vGuDX/tWi4oi4LooD2VR90YvmS/deBi+vPujKk1P4VPEw+ocbkjDU3X7Js/rdKX2zNER WeIK82CCfFu6OpmvB99m4IYLavmBtnyyQusiVoopb170e9Qa2Y4SIZjzsKF3LDTjY1zk RkZA== 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=ltbre0jK5foPCMT2iHcA/nTPUYDIGbPpQW9Z4pK/LFk=; b=BRfb2gokDlAKdLrMoAsuOyl+M4BIkV+kPrBExtQ0uJ2wX72iGM8H0PWKpGl5SctOrP NfAVbwOcKlX0wkTgaXPpbm7St0yDDM0neBt9Cag/nt7hx09rnOMCQCVMLOTwQ+LXcjnG m0tbfsqTB7BJJzVUqrk6qX/G7rQ97dBlvR9OF0IyH1dpAKLdKPSdApc+AJeWrwXBqRQK BIfyHlr2qLIBO82aSPja6M8F9hNb3/P8RSa5uff/ALMV8C9ClBhrRboiKUHbymlDITcg BP6FGA5NNgjBsIuRsrMVNcz672SmIzlZyAi43MWrT7oTHckmS9QdZVRzjfa8/PaiA45m lppA== X-Received: by 10.52.23.49 with SMTP id j17mr755327vdf.56.1372886799401; Wed, 03 Jul 2013 14:26:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.59.71 with HTTP; Wed, 3 Jul 2013 14:25:59 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 3 Jul 2013 14:25:59 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=20cf307c9f32fef1bd04e0a21db7 X-Gm-Message-State: ALoCoQlJnO3w3ceppMR8QttsqolVGIaQv/XNh605ifHJvgMFqZIGLiXlE2YIt9PN0CYYINMAj54yMe+vCEgBJcIwIAL4q/yQunh3U+VgzcncoXIeV58QNZt6vZ2ITLddxQV7vF0s1OvLQjMhd4XlTs7iadLdiPjTTtFZfaS3TsU9Zzy3p6x7u8rPk1CVf2R9+ettVFNunBdX Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 21:26:41 -0000 --20cf307c9f32fef1bd04e0a21db7 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla wrote: > On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher wrote: > >> Camp #0: I've used SDP for years and I'm very comfortable with it. >> Using SDP as the control surface really helps my use case, which is legacy >> interop. Defining an API without SDP would be too much work, and probably >> fail. Look at what happened with SDPng! Supporting all these advanced use >> cases doesn't seem worth it. If developers are doing that much advanced >> stuff, they can learn to munge SDP. It isn't that bad. >> > > Hmm... That's not my understanding of the situation at all. > > Rather, I believe the expectation is that you shouldn't have to modify the > SDP but rather there should be API points to cover most of the use cases > that people want. This isn't to say that all those API points exist or that > they work or whatever. > > -Ekr > > I'm glad to be wrong here. Is the phrase "you shouldn't have to modify the SDP but rather there should be API points to cover most of the use cases" the consensus of the working group? That would be (good) news to me. Because if it's true, then we can just go ahead and add those API points and make the developers happy. Along with that, is "use Jingle for signalling" included in your set of "most of the use cases"? --20cf307c9f32fef1bd04e0a21db7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Camp #0: =C2=A0I've used SDP for= years and I'm very comfortable with it. =C2=A0Using SDP as the control= surface really helps my use case, which is legacy interop. =C2=A0Defining = an API without SDP would be too much work, and probably fail. =C2=A0Look at= what happened with SDPng! =C2=A0Supporting all these advanced use cases do= esn't seem worth it. =C2=A0 If developers are doing that much advanced = stuff, they can learn to munge SDP. =C2=A0It isn't that bad.=C2=A0

Hmm... That's not my under= standing of the situation at all.

Rather, I believ= e the expectation is that you shouldn't have to modify the
SDP but rather there should be API points to cover most of the use cas= es
that people want. This isn't to say that all those API poi= nts exist or that
they work or whatever.

-Ekr


I'm glad to be wrong here. =C2=A0Is the phrase "yo= u shouldn't have to modify the SDP but rather there should be API point= s to cover most of the use cases" =C2=A0the consensus of the working g= roup? =C2=A0That would be (good) news to me. =C2=A0Because if it's true= , then we can just go ahead and add those API points and make the developer= s happy.

Along with that, is "use Jingle for signalling&quo= t; included in your set of "most of the use cases"?=C2=A0

--20cf307c9f32fef1bd04e0a21db7-- From ibc@aliax.net Wed Jul 3 14:35:58 2013 Return-Path: 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 D956E11E8259 for ; Wed, 3 Jul 2013 14:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 p3pfjWfvNlvF for ; Wed, 3 Jul 2013 14:35:53 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id C5A2D11E80EA for ; Wed, 3 Jul 2013 14:35:49 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so3874346qae.6 for ; Wed, 03 Jul 2013 14:35:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=5K3iO+9yu9/WYVDR+0eAxtQbdJNZ0OsVfUKFRlTw3vI=; b=QDoRuVcY9dwWtUXlzraKq1sWFmHsv+vNK8qmv62KTofaq6yuwyd/b0is2iqSl0F80G r5RWpnHdMEWm5g5M2GiNfKplX/Ei4Z/8uWt4JWQEJHrRlCL99LKdIBBw3tFxKQRE9H+s cD8x1nwAVjo78CPK23hBheeCMapJV/J4QI8wBHpaVpwvyY7KGH8aW0en1e6JNIzEPcn3 DQDifMN7OxU4ctn/LFCJBI6RCiymFgtZbMYUxSJb6TQg7AgKbdk+c8pefVQG7iVS5Oba Mv5rrp9/fmgJHCkuomMUHn0mSUrAQdBZ9HkpW+SMQ7kwF30d75JC3Adl8Jm3G98y7Fi8 TlsQ== MIME-Version: 1.0 X-Received: by 10.224.114.207 with SMTP id f15mr6235583qaq.115.1372887348951; Wed, 03 Jul 2013 14:35:48 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Wed, 3 Jul 2013 14:35:48 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Wed, 3 Jul 2013 14:35:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 23:35:48 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Peter Thatcher Content-Type: multipart/alternative; boundary=047d7bdc7de8c04ba904e0a23e2d X-Gm-Message-State: ALoCoQlPvrcl7rx6te6JgQF5jpgSjqYMNDcVFNf/WbOFrW3XPf8JqHDqz7gPMnWsjFq2KfhiCIov Cc: rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 21:35:59 -0000 --047d7bdc7de8c04ba904e0a23e2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 03/07/2013 23:26, "Peter Thatcher" escribi=C3=B3: > > Along with that, is "use Jingle for signalling" included in your set of "most of the use cases"? +1 good question. Hope there is a so good answer for it. Is it? BTW not just Jingle but any (future?) media signaling protocol not based on atomic full SDP blob exchange. Could somebody explain me how to do that without mangling the SDP blob generated by PC? --047d7bdc7de8c04ba904e0a23e2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 03/07/2013 23:26, "Peter Thatcher" <pthatcher@google.com> escribi=C3=B3:
>

> Along with that, is "use Jingle for signalling&quo= t; included in your set of "most of the use cases"?=C2=A0

+1 good question. Hope there is a so good answer for it. Is = it?

BTW not just Jingle but any (future?) media signaling protoc= ol not based on atomic full SDP blob exchange. Could somebody explain me ho= w to do that without mangling the SDP blob generated by PC?

--047d7bdc7de8c04ba904e0a23e2d-- From ekr@rtfm.com Wed Jul 3 14:37:23 2013 Return-Path: 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 8167411E80F7 for ; Wed, 3 Jul 2013 14:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.192 X-Spam-Level: X-Spam-Status: No, score=-102.192 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 LGrI3-SaPO-N for ; Wed, 3 Jul 2013 14:37:17 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 77FB911E80EA for ; Wed, 3 Jul 2013 14:37:17 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c11so411703qcv.23 for ; Wed, 03 Jul 2013 14:37:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=YSIW81SEkHRuXVI7EAnYqQq8UmmeiTrr6XM9TCR+KLs=; b=LGX9fwR2MTZgfNrU9GKNfcynX6ufTJAOTuuo/+IFpHJiXeW2kDtjhj2535t/z64OqM fAQAgi/XZ6LqD0EOjSxseMIpEYDA3UvPqfGd9BuIb+ILfaNzkp5Ug7S2FQf/DH3+KL2m GyBGL9GRzAiIONJz3Z0IvV2k/OEMR7udbBCFKvsz4SNYSRXN8UFwbFkH5ZTzkzYoZRD3 gMsZ5WkvpMEg5Vmn1u2pZ99qy4QJdsAYKkfzUhO2ebxxz3MbqliLIdtbhhRqtrEXX5Pp WjByXTvclkThTWGm9MqrIe91NcgJWB0KCUe34BSeuTrO2gJ3OlV0zDdc+rf4u8MSlOJi iKDQ== X-Received: by 10.224.115.5 with SMTP id g5mr6275088qaq.53.1372887437001; Wed, 03 Jul 2013 14:37:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 3 Jul 2013 14:36:36 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 3 Jul 2013 14:36:36 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=047d7bdc9514ffd74204e0a243ca X-Gm-Message-State: ALoCoQlM0EFdi68E32/9RVefDx/2NwvWyq8NblAeUwVcNyGEeDaI/KOlmYYus+ltmH6Om6C13lP3 Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 21:37:23 -0000 --047d7bdc9514ffd74204e0a243ca Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher wrote: > On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla wrote: > >> On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher wrote: >> >>> Camp #0: I've used SDP for years and I'm very comfortable with it. >>> Using SDP as the control surface really helps my use case, which is legacy >>> interop. Defining an API without SDP would be too much work, and probably >>> fail. Look at what happened with SDPng! Supporting all these advanced use >>> cases doesn't seem worth it. If developers are doing that much advanced >>> stuff, they can learn to munge SDP. It isn't that bad. >>> >> >> Hmm... That's not my understanding of the situation at all. >> >> Rather, I believe the expectation is that you shouldn't have to modify the >> SDP but rather there should be API points to cover most of the use cases >> that people want. This isn't to say that all those API points exist or >> that >> they work or whatever. >> >> -Ekr >> >> > I'm glad to be wrong here. Is the phrase "you shouldn't have to modify > the SDP but rather there should be API points to cover most of the use > cases" the consensus of the working group? > I thought it was, but I'm not the chair, so maybe you could ask Harald or Stefan. Along with that, is "use Jingle for signalling" included in your set of > "most of the use cases"? > No, I don't think it is, since it's not SDP. Maybe I could phrase this differently: It was my understanding that you should have API points to get the PC to emit SDP that would express the policies, preferences, actions, etc. that the application wants. If you want something that's not SDP you would need to gateway. This may or may not be a satisfactory state of affairs, but it was the rule I was using (based on what I thought the WG expected) for when use cases needed new API points. -Ekr --047d7bdc9514ffd74204e0a243ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher <ptha= tcher@google.com> wrote:
On Wed, Jul 3, 20= 13 at 2:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:
On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher <p= thatcher@google.com> wrote:
Camp #0: =A0I've used SDP for ye= ars and I'm very comfortable with it. =A0Using SDP as the control surfa= ce really helps my use case, which is legacy interop. =A0Defining an API wi= thout SDP would be too much work, and probably fail. =A0Look at what happen= ed with SDPng! =A0Supporting all these advanced use cases doesn't seem = worth it. =A0 If developers are doing that much advanced stuff, they can le= arn to munge SDP. =A0It isn't that bad.=A0

Hmm... That's not my under= standing of the situation at all.

Rather, I believ= e the expectation is that you shouldn't have to modify the
SDP but rather there should be API points to cover most of the use cas= es
that people want. This isn't to say that all those API poi= nts exist or that
they work or whatever.

-Ekr


I'm glad to be wrong here. =A0Is the phrase= "you shouldn't have to modify the SDP but rather there should be = API points to cover most of the use cases" =A0the consensus of the wor= king group? =A0

I thought it was, but I&= #39;m not the chair, so maybe you could ask Harald or
Stefan.


Along with that, is "use Jingle for signalling" included in your = set of "most of the use cases"?=A0

No, I don't think it is, since it's= not SDP.

Maybe I could phrase this differently: It w= as my understanding that you should have
API points to get = the PC to emit SDP that would express the policies, preferences,
actions, etc. that the application wants. If you want something that's = not SDP you would
need to gateway.

This may or may not be a satisfactory state of affairs, but it= was the rule I was using
(based on what I thought the WG expected) for when use cases nee= ded new API
points.

-Ekr
=A0

--047d7bdc9514ffd74204e0a243ca-- From ibc@aliax.net Wed Jul 3 14:42:46 2013 Return-Path: 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 E1B4D11E8219 for ; Wed, 3 Jul 2013 14:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 WY1qLaiNoA0e for ; Wed, 3 Jul 2013 14:42:42 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC9611E80EE for ; Wed, 3 Jul 2013 14:42:42 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id f11so450165qae.10 for ; Wed, 03 Jul 2013 14:42:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=6Kw4pbS1dYpNdR0Z6O7hehKOx5jfGLqYW+ZFBiyPNrI=; b=XaUrPdJQKORdhRPk3P5qkYzTaSHCN0OaiOKUZKHTepIM9zSHgVm5g0xDEjVRMAZWS6 NyBtNP/q+RQ+loy3qr1jCTauAvRzh4GeXioUUmj42yCAdYEdEmpbZyBMmwclXxdYP9dd tFM8Q81A0jRJ3rBOvD/YYuGjcu6EOcC6zYvXUYkEG74T/LClCL+fMmqvCl58+wXwRP3/ TFfctny23EW8AlTpBnMx0nh3Z14nICmoZ16b31tTqPyG887cJiiH0rhT+3aBHI82+3zu PFOcErCnBku15Sse0lboAG/3ZwmE5FCRz+1eQuvaVX8wq3mR9qt1UZdsHG+IAYCLEmNI gUWw== MIME-Version: 1.0 X-Received: by 10.49.116.176 with SMTP id jx16mr3659333qeb.52.1372887761814; Wed, 03 Jul 2013 14:42:41 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Wed, 3 Jul 2013 14:42:41 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Wed, 3 Jul 2013 14:42:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 23:42:41 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b6d8b765c1da804e0a25760 X-Gm-Message-State: ALoCoQlD/NxKag28nMRW9Ml7RhR+K4wZe6ZdwKYTVy3ZSC9p/9I9iQhx0PPY1F0o3zvhtWN4RTMA Cc: rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 21:42:47 -0000 --047d7b6d8b765c1da804e0a25760 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So compatibility with SIP is important but compatibility with Jingle is just impossible. And this is supposed to be the API proposed to W3C... -- I=C3=B1aki Baz Castillo El 03/07/2013 23:37, "Eric Rescorla" escribi=C3=B3: > On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher wrot= e: > >> On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla wrote: >> >>> On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher wr= ote: >>> >>>> Camp #0: I've used SDP for years and I'm very comfortable with it. >>>> Using SDP as the control surface really helps my use case, which is l= egacy >>>> interop. Defining an API without SDP would be too much work, and prob= ably >>>> fail. Look at what happened with SDPng! Supporting all these advance= d use >>>> cases doesn't seem worth it. If developers are doing that much advan= ced >>>> stuff, they can learn to munge SDP. It isn't that bad. >>>> >>> >>> Hmm... That's not my understanding of the situation at all. >>> >>> Rather, I believe the expectation is that you shouldn't have to modify >>> the >>> SDP but rather there should be API points to cover most of the use case= s >>> that people want. This isn't to say that all those API points exist or >>> that >>> they work or whatever. >>> >>> -Ekr >>> >>> >> I'm glad to be wrong here. Is the phrase "you shouldn't have to modify >> the SDP but rather there should be API points to cover most of the use >> cases" the consensus of the working group? >> > > I thought it was, but I'm not the chair, so maybe you could ask Harald or > Stefan. > > > Along with that, is "use Jingle for signalling" included in your set of >> "most of the use cases"? >> > > No, I don't think it is, since it's not SDP. > > Maybe I could phrase this differently: It was my understanding that you > should have > API points to get the PC to emit SDP that would express the policies, > preferences, > actions, etc. that the application wants. If you want something that's > not SDP you would > need to gateway. > > This may or may not be a satisfactory state of affairs, but it was the > rule I was using > (based on what I thought the WG expected) for when use cases needed new A= PI > points. > > -Ekr > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b6d8b765c1da804e0a25760 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So compatibility with SIP is important but compatibility wit= h Jingle is just impossible. And this is supposed to be the API proposed to= W3C...

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

El 03/07/2013 23:37, "Eric Rescorla" &= lt;ekr@rtfm.com> escribi=C3=B3:
On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher <ptha= tcher@google.com> wrote:
On Wed, Jul 3, 20= 13 at 2:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:
On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher <p= thatcher@google.com> wrote:
Camp #0: =C2=A0I've used SDP for= years and I'm very comfortable with it. =C2=A0Using SDP as the control= surface really helps my use case, which is legacy interop. =C2=A0Defining = an API without SDP would be too much work, and probably fail. =C2=A0Look at= what happened with SDPng! =C2=A0Supporting all these advanced use cases do= esn't seem worth it. =C2=A0 If developers are doing that much advanced = stuff, they can learn to munge SDP. =C2=A0It isn't that bad.=C2=A0

Hmm... That's not my under= standing of the situation at all.

Rather, I believ= e the expectation is that you shouldn't have to modify the
SDP but rather there should be API points to cover most of the use cas= es
that people want. This isn't to say that all those API poi= nts exist or that
they work or whatever.

-Ekr


I'm glad to be wrong here. =C2=A0Is the phr= ase "you shouldn't have to modify the SDP but rather there should = be API points to cover most of the use cases" =C2=A0the consensus of t= he working group? =C2=A0

I thought it was, but I&= #39;m not the chair, so maybe you could ask Harald or
Stefan.


Along with that, is "use Jingle for signalling" included in your = set of "most of the use cases"?=C2=A0

No, I don't think it is, since it's no= t SDP.

Maybe I could phrase this differently: It was my unders= tanding that you should have
API points to get the PC to emit SDP= that would express the policies, preferences,
actions, etc. that the application wants. If you want something that's = not SDP you would
need to gateway.

This = may or may not be a satisfactory state of affairs, but it was the rule I wa= s using
(based on what I thought the WG expected) for when use cases needed ne= w API
points.

-Ekr
=C2=A0


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

--047d7b6d8b765c1da804e0a25760-- From hadriel.kaplan@oracle.com Wed Jul 3 14:43:27 2013 Return-Path: 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 28EC411E8267 for ; Wed, 3 Jul 2013 14:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 QQXvG+4wYrey for ; Wed, 3 Jul 2013 14:43:21 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id B924011E8262 for ; Wed, 3 Jul 2013 14:43:21 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r63LawmI025340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Jul 2013 21:36:59 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r63LhIYj012300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 21:43:19 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r63LhI6P019526; Wed, 3 Jul 2013 21:43:18 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Jul 2013 14:43:18 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51CA6FEE.6030702@hookflash.com> Date: Wed, 3 Jul 2013 17:43:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <093EDF0B-AFEA-4979-AC72-23AF2FC5E8C7@oracle.com> References: <51CA6FEE.6030702@hookflash.com> To: Robin Raymond X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 21:43:27 -0000 You might also want to cite some of the reasons noted in this old draft: http://tools.ietf.org/html/draft-kaplan-rtcweb-api-reqs-01 -hadriel On Jun 26, 2013, at 12:37 AM, Robin Raymond wrote: >=20 > According > to many, real adoption of WebRTC will not happen if we continue to=20 > force everyone to use this SDP Offer/Answer methodology. It is = clearly=20 > blocking our way forward and the amount of specification documentation=20= > remaining needed for the browser vendors to produce a compatible SDP=20= > based WebRTC engine in a browser is much more daunting than most are=20= > willing to admit. >=20 >=20 > The > draft rationale behind a JavaScript Object API model: >=20 > = http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api= -rationale-00.txt >=20 > =20 >=20 > Whereas: > The > WebRTC JavaScript Object API & Shim document will be along shortly. >=20 >=20 > We > wanted to get this initial rationale draft informational document out=20= > right away. Everyone that has any interest should review the reasons = and > concepts and comment before we get too far along on the details of an=20= > actual API, the initial API will follow in the coming days. >=20 >=20 > Best > regards, >=20 > Robin > Raymond > =20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Wed Jul 3 15:05:51 2013 Return-Path: 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 0E10211E80F6 for ; Wed, 3 Jul 2013 15:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.085 X-Spam-Level: X-Spam-Status: No, score=-102.085 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ZAN-CFMQRlwp for ; Wed, 3 Jul 2013 15:05:38 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id B07B121F9D9F for ; Wed, 3 Jul 2013 15:05:37 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id 1so417700qec.20 for ; Wed, 03 Jul 2013 15:05:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=DYPwaSxYoUUyGdguPl517BccnMDOJY1KcAkVOvH/Tng=; b=oIqYhL+kFVh7dVJjItPxo4HOJ2E+RAg4ghcNsa9jTi+trL2c8ndA1lrBm0BKS6KD3U YQOtVyGvKbxBbYYnxSxC+LHOfklDFLoLgckbTxPfDUB3x78oda98Y7I/+771NAmxqO6h 5Xm01GMsEhaTJCMJl1n0uyLLazj6hPo+Sc4f9Qs2EMzH7gFChni+RSEov9TMx0rZ19VG 6v65XZfXpIVBIJx5PSUXh2Shnv9Spt2bhS4qyq0hN7MTr47Zg968QL5SH1aziGvt5xeO 7ASWYj5v5m9mXbSbGnXEiCjiYNGHln5/kkNaifpRRZTAxerBZfbX4CwGGc2Xb3d1tghS 4o0A== X-Received: by 10.229.173.202 with SMTP id q10mr864755qcz.64.1372889136981; Wed, 03 Jul 2013 15:05:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 3 Jul 2013 15:04:56 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 3 Jul 2013 15:04:56 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a1132eee653848704e0a2a900 X-Gm-Message-State: ALoCoQktZbZ8f+FfWzZFblrqvDUuEOxrc1Gkvi2bXig8dTlWjs3ddRedVzsSYuTU9xCAPvmbQmU/ Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:05:51 -0000 --001a1132eee653848704e0a2a900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 2:42 PM, I=F1aki Baz Castillo wrote: > So compatibility with SIP is important but compatibility with Jingle is > just impossible. And this is supposed to be the API proposed to W3C... > Who said anything about impossible? It's a mechanical transformation (see: http://xmpp.org/extensions/xep-0167.html). Anyway, it's not like this feature is a surprise to anyone--well at least anyone who was paying attention--it's been a feature of the specification since before the WG was even formed. As I said earlier, it was in the original WHATWG spec that Ian Hickson wrote. -Ekr --001a1132eee653848704e0a2a900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 2:42 PM, I=F1aki Baz Castillo <ibc@ali= ax.net> wrote:

So compatibility with SIP is important but = compatibility with Jingle is just impossible. And this is supposed to be th= e API proposed to W3C...

Who said anything about impossible? It's a mechanical= transformation

Anyway, it's not like this feature is a surprise to anyone--= well at
least anyone who was paying attention--it's bee= n a feature of the
specification since before the WG was ev= en formed. As I said
earlier, it was in the original WHATWG spec that Ian Hickson
wrote.

-Ekr

<= /div>


--001a1132eee653848704e0a2a900-- From martin.thomson@gmail.com Wed Jul 3 15:07:47 2013 Return-Path: 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 502F911E823E for ; Wed, 3 Jul 2013 15:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 MksE3+veCwF4 for ; Wed, 3 Jul 2013 15:07:46 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 77E0211E80F6 for ; Wed, 3 Jul 2013 15:07:45 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so566505wes.32 for ; Wed, 03 Jul 2013 15:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WrKlYZmQ7I2Kl+1vGDSvyP56FKcYMB7M68cmrSN9CCo=; b=HwyhvroAe6BxwZfkd3hVqmKCDtzCLh3Ljyg3URYO9VjQOqB3+OOrYynWJuEa1s7+U1 u19yURKPyTijux/LgmCZIa32SI5fz9WYX7xv3m9lmACvi068KsuLr3BY8WSQI+QDT6dN /Lsi9mt1hEQirRKvR4B9v1wsUTNNNxbYIx2cR2EjTFVV8AMqIrEzUCd9ZVVfVGbAgsli 6MMWOgyEd0cNm9yyRHCyFWzFlMhXsc5Zjj8ekOlXkmXZpxeNqNQpl9T4GKQekdcZku50 m+SRgZnuaZ/PsXYaU7fAL9uBmlNWidCPUMpMMbTiX2CyJG27htGTxt588IVtuvMuFfME Pu/Q== MIME-Version: 1.0 X-Received: by 10.194.110.6 with SMTP id hw6mr1902799wjb.3.1372889265301; Wed, 03 Jul 2013 15:07:45 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Wed, 3 Jul 2013 15:07:45 -0700 (PDT) In-Reply-To: <093EDF0B-AFEA-4979-AC72-23AF2FC5E8C7@oracle.com> References: <51CA6FEE.6030702@hookflash.com> <093EDF0B-AFEA-4979-AC72-23AF2FC5E8C7@oracle.com> Date: Wed, 3 Jul 2013 15:07:45 -0700 Message-ID: From: Martin Thomson To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:07:47 -0000 On 3 July 2013 14:43, Hadriel Kaplan wrote: > You might also want to cite some of the reasons noted in this old draft: > http://tools.ietf.org/html/draft-kaplan-rtcweb-api-reqs-01 Yes. This is an excellent draft that covers a lot of the same issues. I especially like: 4) That when a IETF documents start telling you how to build Javascript APIs, you should run far away... quickly. :) From pthatcher@google.com Wed Jul 3 15:17:35 2013 Return-Path: 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 69E3E11E8244 for ; Wed, 3 Jul 2013 15:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 Aok+ujQ12GLh for ; Wed, 3 Jul 2013 15:17:34 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9B51A11E80E2 for ; Wed, 3 Jul 2013 15:17:34 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so487805pdi.30 for ; Wed, 03 Jul 2013 15:17:34 -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=OcAI/PjB71WtGUrKdI2l1jMQOxIwBLAI4NEmzob6l+U=; b=ekhGz9wZvLmMNnCSVfsTiR9wyXOi5QPCgkRIXALFqGnw3TwXaw5p15ViuWC8HVCWwS obzrvHb8EPulZOloxnEoUnhpF07De9BAiVi9fua6F2m4fLJZ/LVublgBFFV8KMxtGIiN wKqOD5hi2qJpfWLYTUmTKGH3UQS2KMWAvoH7PMl9Dr/zIEmLmySuZpbDaUFnU0mp70zb B2c5wSC02CvmPdakv662Rz7ljui9QD/im5qdPu8homRYC31fUlNiFVNTjKmSMQ7A4LhV ew6p03QDevJANlsnKQf70Es7P6bv2gHh9D5kjTOEwdWnGLg+OtaI4yN+omscsellZNQo jeMw== 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=OcAI/PjB71WtGUrKdI2l1jMQOxIwBLAI4NEmzob6l+U=; b=g9fXTV4f7LcEseu3Yk+ETQj4Oo3VulPoWJl1U+v8N6NFDWEUjfQ9lptMeCurgTcuww TPqtyxe486W7aUd9qRHKjiFt0m3KKTyOGWuEmEwglTFT/C0zCngP3YLMh2t90bQbRaxI hBUEDgsZ31CCyWT6dboL7Tch6HocSSX8RxAGcx1ds92WcC+5x6hJX6yiyTwNJZD+4UgS ZNTK2UBXmHbxdurJetu9NcPqvZaCaWym3cksx308S0Yyxyhv6JVWYcM8Co4CZrSTkQEJ aNSzRTRuUr6XCFRCpJzrQBgA06we33avVm1doHaGEzvbQt4wUH2D0PWEVsqq4YTTWHw2 aMrA== X-Received: by 10.66.14.196 with SMTP id r4mr4412742pac.57.1372889854230; Wed, 03 Jul 2013 15:17:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Wed, 3 Jul 2013 15:16:54 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 3 Jul 2013 15:16:54 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec51f99e513f0f804e0a2d43d X-Gm-Message-State: ALoCoQlBNmHJgrnp2xVTyzHkxaaDIa81VRR2dLzxvifQZe7FI5Noq18VNEWCgOrmjcntCOfOlWu8d32BBtHt3oESOz9+SSbwQrLUsn50B1ovaJ542cvTwNVOYQBPTs1gUjN8YN9fZP18IGPl/3D1rHZ+e/xXukvPSsg/ApkLqfGd2OyFBugotEmdszc/4sye/xFuaduzbj3S Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:17:35 -0000 --bcaec51f99e513f0f804e0a2d43d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 3:04 PM, Eric Rescorla wrote: > On Wed, Jul 3, 2013 at 2:42 PM, I=C3=B1aki Baz Castillo w= rote: > >> So compatibility with SIP is important but compatibility with Jingle is >> just impossible. And this is supposed to be the API proposed to W3C... >> > Who said anything about impossible? It's a mechanical transformation > (see: http://xmpp.org/extensions/xep-0167.html). > > Anyway, it's not like this feature is a surprise to anyone--well at > least anyone who was paying attention--it's been a feature of the > specification since before the WG was even formed. As I said > earlier, it was in the original WHATWG spec that Ian Hickson > wrote. > > -Ekr > > There are lots of application developers who weren't around back then, so it's not reasonable to expect them to have been paying attention back then. Many are very new to this, and there are lots of surprises for them. And as many developers are now trying to use the WebRTC API, we're now getting feedback on how well it works for them. The point of my original post in this thread was to summarize the feedback we've received so far for the WG. It wasn't my intention to re-start arguments between one camp and another. But your clarification of "Camp #0" was helpful, so thank for you for that. --bcaec51f99e513f0f804e0a2d43d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 3, 2013 at 3:04 PM, Eric Rescorla <= ;ekr@rtfm.com> wrote:
On Wed, Jul 3, 2013 at= 2:42 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

So compatibility with SIP is important but = compatibility with Jingle is just impossible. And this is supposed to be th= e API proposed to W3C...

Who said anything about impossible? It's a mech= anical transformation

Anyway, it's not like this feature is a surprise to anyone--well a= t
least anyone who was paying attention--it's been a feature = of the
specification since before the WG was even formed. As I sa= id
earlier, it was in the original WHATWG spec that Ian Hickson
wrote.

-Ekr

<= /div>

There are lots of application develop= ers who weren't around back then, so it's not reasonable to expect = them to have been paying attention back then. =C2=A0Many are very new to th= is, and there are lots of surprises for them.

And as many developers are now trying to use the = WebRTC API, we're now getting feedback on how well it works for them. = =C2=A0The point of my original post in this thread was to summarize the fee= dback we've received so far for the WG.

It wasn't my intention to re-start arguments betwee= n one camp and another. =C2=A0 But your clarification of "Camp #0"= ; was helpful, so thank for you for that.


--bcaec51f99e513f0f804e0a2d43d-- From ibc@aliax.net Wed Jul 3 15:17:47 2013 Return-Path: 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 3FF6011E80E2 for ; Wed, 3 Jul 2013 15:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 EGzbllOj91De for ; Wed, 3 Jul 2013 15:17:42 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 18B8511E824A for ; Wed, 3 Jul 2013 15:17:42 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so423594qej.39 for ; Wed, 03 Jul 2013 15:17:41 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=ygBIKgdD6Kl+Fxhq0CjZR9OmFazARoTjUojLsmnMm6I=; b=BsvGOwVe2Moz+OkXBPIyBBk0arCvtUS420fVWf+CcNOjk981IulZ780i0cDO2KpM+T It5wq9wRF8KmBjkPZKgmo/m3kjda7lbrmatu73vmkggrqVZxuYnVpol3l0pF2c34I89B Ch/TMAy9FmzpykK4FOSu46pg/OTWDOBUrZq/qhWCXSlE9U0HxjCmNEEIyhSF+i3xPdyc yLHSwjbRabIYZl0veeL6tPuzWsEdstdg+bcRQnDUl5zZb43eh5mUYOa8JmV6oPWYtkun lU/DzIO/4QNwL7v7maCJwID3R+YgPfwlYFQLYl0kORS9VBA+CPiyqo0D3JAPms8uAH0j dlYg== X-Received: by 10.224.90.1 with SMTP id g1mr6650638qam.0.1372889861518; Wed, 03 Jul 2013 15:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 3 Jul 2013 15:17:21 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 4 Jul 2013 00:17:21 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlVbvDTCbyaDMMl1ldZLQ12d/jo18utrXpFc5mhATsguD9iXkg7wK6C63zNKcxXu76F3rt1 Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:17:47 -0000 2013/7/4 Eric Rescorla : > Anyway, it's not like this feature is a surprise to anyone--well at > least anyone who was paying attention--it's been a feature of the > specification since before the WG was even formed. As I said > earlier, it was in the original WHATWG spec that Ian Hickson > wrote. I know, and I was a "SDP supporter" at the beginning (and much others like me who, after dealing with it for something more than just single audio+video phone calls, have changed their mind). I don't consider that such a "original WHATWG spec" is written in a stone. It was an initial proposal after all. Nothing prevents it to be radically modified/improved now. Best regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Jul 3 15:21:03 2013 Return-Path: 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 B4E5511E80F9 for ; Wed, 3 Jul 2013 15:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 I57tIM+A7j9n for ; Wed, 3 Jul 2013 15:20:59 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA47C21F9ABC for ; Wed, 3 Jul 2013 15:20:49 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id o13so3939994qaj.10 for ; Wed, 03 Jul 2013 15:20:49 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=KsOcLvdmX4FhCPtUZAGZNRjg8plklmcadZK3Kl/Mkag=; b=bH7cQkwSSk2eUVEjhwWuYTEjhHQteqvQCUiOtZgDgWO4qLRvfHLoW3LxMYqSKHyMbV mF+izeILomjvy8DRWvVH1FbHvSiWiLIqA7hakaIqExqTmV/hKggNLVjxTvn5UsEXYiiZ Jd+16N8eYhMar9KdzqxW4ZrD2eSZxkj835kxj/wTNX/jPz6gZAQ/9Oc2pPCwlUbiv900 07+epOb7hB1H0fMyLD4NJcy+IZkgI5kBRkUiSlQ93iA8lkbOuUqO3IcpSjFOaZclzuBD gxVw9361eQG2tH9EDbDtkAdXguP5jYLbMKRn3UdznnSgbbM8cDfFxkyfB5niPrTnOx8S RCDg== X-Received: by 10.49.84.164 with SMTP id a4mr3972296qez.4.1372890049342; Wed, 03 Jul 2013 15:20:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 3 Jul 2013 15:20:26 -0700 (PDT) In-Reply-To: <093EDF0B-AFEA-4979-AC72-23AF2FC5E8C7@oracle.com> References: <51CA6FEE.6030702@hookflash.com> <093EDF0B-AFEA-4979-AC72-23AF2FC5E8C7@oracle.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 4 Jul 2013 00:20:26 +0200 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQllkSRgSALig8z2XWWby/r8lQA3VAO513JMpI8bbTtaQHz8PSkPmAUuY0wjyWw5aUjSDJw1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:21:03 -0000 2013/7/3 Hadriel Kaplan : > You might also want to cite some of the reasons noted in this old draft: > http://tools.ietf.org/html/draft-kaplan-rtcweb-api-reqs-01 Well, section "3. Defining a WebRTC Protocol in the Browser" says: 9) Using the SDP offer/answer model provides a more rigid API interaction model, enabling Browser vendors to perform less testing and provide more robust implementations than exposing all discrete components to a Javascript API would. 10) Using a higher-level API model, such as would be done with an SDP offer/answer model, means the cross-browser vendor-specific variances would be reduced. Exposing a lower-level API would inevitably lead to some differences in different browsers due to differences in their architectures/implementation. Time to reconsider those assertions? ;) -- I=C3=B1aki Baz Castillo From ekr@rtfm.com Wed Jul 3 15:21:42 2013 Return-Path: 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 312C611E80E0 for ; Wed, 3 Jul 2013 15:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 7-fPnIZjdBtC for ; Wed, 3 Jul 2013 15:21:30 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A27121F9AC9 for ; Wed, 3 Jul 2013 15:21:29 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id j10so445943qcx.3 for ; Wed, 03 Jul 2013 15:21:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=F00q1QNJ0VolPGFmz4P2+M8N8DhFo3IunX5DmlOgnTk=; b=ppltA0Wf6wPTglbezSa6Vu/KMH456rgmlr0WZH840pS7mFOu63i8NTtBAE0cswOlpS RK7upzNdd2qXgemRYP0Omno5xVjsNQ76U/lMiXxqA8CGRq/3hB3+IwcdIzz8i3Pg+k/M Q4PmWFiyogcDHpy8fefmGKzZoYBY3HmTXJHvRIuNZs7uBqbkTg7AgXcBi401J3cCDLZP 8W2bu55YXS1mDAX680a3uJrWskUJ2k4uSacMhY0YMxZ0na12J7w7yDPe0ymI3AmjUswA qpyduZGc1bA/35oTL30ZGXop/DzjHSkckv73N84fKcvs1wemInOKTeUlomp3zcddSHMh JJLA== X-Received: by 10.224.174.6 with SMTP id r6mr6219180qaz.87.1372890089462; Wed, 03 Jul 2013 15:21:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 3 Jul 2013 15:20:49 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 3 Jul 2013 15:20:49 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=485b397dd205192c6d04e0a2e24a X-Gm-Message-State: ALoCoQm11AoPwO6We4pUpYzLSnR9gkaQ77DmsZkfhiZE459OzyUGevZ1MxYH2K1lL6Ghxe/OC75s Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:21:42 -0000 --485b397dd205192c6d04e0a2e24a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 3:16 PM, Peter Thatcher wrote= : > > > > On Wed, Jul 3, 2013 at 3:04 PM, Eric Rescorla wrote: > >> On Wed, Jul 3, 2013 at 2:42 PM, I=F1aki Baz Castillo wro= te: >> >>> So compatibility with SIP is important but compatibility with Jingle is >>> just impossible. And this is supposed to be the API proposed to W3C... >>> >> Who said anything about impossible? It's a mechanical transformation >> (see: http://xmpp.org/extensions/xep-0167.html). >> >> Anyway, it's not like this feature is a surprise to anyone--well at >> least anyone who was paying attention--it's been a feature of the >> specification since before the WG was even formed. As I said >> earlier, it was in the original WHATWG spec that Ian Hickson >> wrote. >> >> > There are lots of application developers who weren't around back then, > so it's not reasonable to expect them to have been paying attention back > then. Many are very new to this, and there are lots of surprises for the= m. > The person I was responding to has posts on this mailing list going back as far as September 2011. -Ekr --485b397dd205192c6d04e0a2e24a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 3, 2013 at 3:16 PM, Peter Thatcher &l= t;pthatcher@googl= e.com> wrote:



On Wed, Jul 3= , 2013 at 3:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:
On Wed, Jul 3, 2013 at= 2:42 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:

So compatibility with SIP is important but = compatibility with Jingle is just impossible. And this is supposed to be th= e API proposed to W3C...

Who said anything about impossible? It's a mech= anical transformation

Anyway, it's not like this feature is a surprise to anyone--well a= t
least anyone who was paying attention--it's been a feature = of the
specification since before the WG was even formed. As I sa= id
earlier, it was in the original WHATWG spec that Ian Hickson
wrote.

=A0
=
There are lots of application developers who weren't around = back then, so it's not reasonable to expect them to have been paying at= tention back then. =A0Many are very new to this, and there are lots of surp= rises for them.

The person I was r= esponding to has posts on this mailing list going back as far as September = 2011.

-Ekr

--485b397dd205192c6d04e0a2e24a-- From ekr@rtfm.com Wed Jul 3 15:28:30 2013 Return-Path: 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 CA3AA21F9BCB for ; Wed, 3 Jul 2013 15:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.852 X-Spam-Level: X-Spam-Status: No, score=-101.852 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 c2sDV9Jwc9wf for ; Wed, 3 Jul 2013 15:28:25 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC84721F9BCA for ; Wed, 3 Jul 2013 15:28:24 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so430242qeb.31 for ; Wed, 03 Jul 2013 15:28:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=jEFM09GlefLLVON7UYgWUSPskHsprdcRg3XlAGkvBkw=; b=bRoX9xKMlQE0SZnJvzz9F7f9Ev2c6bu/i/s0fVt4kHsTBa2DPR63abAmSQeeMqVxjT q9nWeDETOmSvKWrI69XZcRRKK3uycXF4Bs55aSEkUIED8cS5rrBRiMhx7XruAZo6/sFs mz7Z5f1ae8Y8F+woHBBalaEz0crBHUFHAlVNVt0TmTRmZkvX+WhwMzXuZMzDhJ4Ta0hV KrAuRV5BXv7RqGHC6xNpgqfh2kLqKu3zRNREudYSQQ5uvwDoSK4mr9EtOJ7FJHXmQQcS BOOniS1X9Xxa9825OOu5ZGSHwHhBBJH6ZLZw9HIWhzMQM2Bn8gDdgy0tULrIh3+5lbaH ZmKw== X-Received: by 10.49.104.72 with SMTP id gc8mr3887177qeb.35.1372890503340; Wed, 03 Jul 2013 15:28:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 3 Jul 2013 15:27:43 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 3 Jul 2013 15:27:43 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b677510c4773c04e0a2fa8a X-Gm-Message-State: ALoCoQn+jA8ZqnZXXBrbMizzG62egp/qIBItjqsXVTMRyMthwQTmk+sBOXdAasJ+gXwQ3BnWlP4N Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:28:30 -0000 --047d7b677510c4773c04e0a2fa8a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 3:17 PM, I=F1aki Baz Castillo wrote: > 2013/7/4 Eric Rescorla : > > Anyway, it's not like this feature is a surprise to anyone--well at > > least anyone who was paying attention--it's been a feature of the > > specification since before the WG was even formed. As I said > > earlier, it was in the original WHATWG spec that Ian Hickson > > wrote. > > I know, and I was a "SDP supporter" at the beginning (and much others > like me who, after dealing with it for something more than just single > audio+video phone calls, have changed their mind). This leaves me puzzled by your complaint that the current specification doesn't support Jingle out of the box, since that's been obvious from the very beginning and it's not like that's something that required extensive developer experience to discern. If this is important, why didn't you complain then? -Ekr --047d7b677510c4773c04e0a2fa8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 3, 2013 at 3:17 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2013/7/4 Eric Rescorla <ekr@rtfm.com>:
> Anyway, it's not like this feature is a surprise to anyone--w= ell at
> least anyone who was paying attention--it's been a feature of the<= br> > specification since before the WG was even formed. As I said
> earlier, it was in the original WHATWG spec that Ian Hickson
> wrote.

I know, and I was a =A0"SDP supporter" at the beginning (an= d much others
like me who, after dealing with it for something more than just single
audio+video phone calls, have changed their mind).=A0

=
This leaves me puzzled by your complaint that the current s= pecification
doesn't support Jingle out of the box, since tha= t's been obvious from the
very beginning and it's not like that's something that require= d extensive
developer experience to discern. If this is important= , why didn't you
complain then?

-Ekr
--047d7b677510c4773c04e0a2fa8a-- From pthatcher@google.com Wed Jul 3 15:28:49 2013 Return-Path: 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 2FF3E21F9BF1 for ; Wed, 3 Jul 2013 15:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 sz+-1LtJKGVU for ; Wed, 3 Jul 2013 15:28:48 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5788A21F9BCA for ; Wed, 3 Jul 2013 15:28:48 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so679035pad.33 for ; Wed, 03 Jul 2013 15:28:48 -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=JkiPGc3uD8GhCS4OxyugJdbgQ2gYtBW6z0VKJBI/zzI=; b=nkSEmSrwwaurCeNlejo1j6SYg0URRUs7bRKTeutvymfEgwAsA1gsHk7wTFWz0yH5nL N0fYM5puif3QaXBzh8aC9ndzFv1Tqr7D79Pv5WV6/ciwtgcGqBpbJQOc76fr2ym3LGhM /PCR4cJtVGfvgpNE0v6m9E7AQavpyiELa+CxEfncI++6sLTaiAODbbKRHAnTRl9nIMUD GkP9sO76bph8hNxX8FD9ZCjDs6sbaetmA6C61ZxuF5Gw57U0wCsZudCKgpiYC7uki5hD VS/Xb2oINgc8QXJuMmUyxqRUyLqPPKAxP0w1fVvFn9KbOwny7xRRINKfvn3gJfdff24H KpAQ== 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=JkiPGc3uD8GhCS4OxyugJdbgQ2gYtBW6z0VKJBI/zzI=; b=dAE9H+n+1mMSCASGscr3V9papylL0oN0s63huVGu36EX2TmkXmXBVboM3U1aFLkYGU GTrLyMB2/GjMQWX8rkz93DInphoKnMOLi1H4BEH2ODdKQPJjNUOKwtGsyyzq7tqYSUIX iOqFtfyIjSydzvUFMYJhYdvImvw2BC8J3Bbwl6CMMymBa0avfB06EM2oS4Gqq25Jlpwh fvanBToQLoPCVy2iZzc3dtGmbBPEp9vQVBkO/YN87GQoTJJX5/3nZXtV8amUsWnAoMp/ Eunoup2CxjlGgMwM0YUcnUvp1VzhBD9VQl1s/4oq/nIycqZ03nYyQUoDJf3182WJeW41 VCxg== X-Received: by 10.68.213.5 with SMTP id no5mr2708004pbc.185.1372890528057; Wed, 03 Jul 2013 15:28:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Wed, 3 Jul 2013 15:28:07 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 3 Jul 2013 15:28:07 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=e89a8fb208343dbc9c04e0a2fc14 X-Gm-Message-State: ALoCoQlSyvVxJJGlLTqWVCClLz2Xsk9e9by23nxSJiv+1GvVkU4hMMaJutZfUTFSEHrWZulMyZ5JYuABbU9XI2skKqoBW5BTj9WoUgzAGlOAXCKgohEkzz1wyz3ORUShG71KpNGz2/CkBEAQ+2zacfpNTfqyH9vXegoh2/Zc3MOyJSMtlRiQIRqEUz+LBgsygD6cAfGkdRWv Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:28:49 -0000 --e89a8fb208343dbc9c04e0a2fc14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 3:20 PM, Eric Rescorla wrote: > > > > On Wed, Jul 3, 2013 at 3:16 PM, Peter Thatcher wrot= e: > >> >> >> >> On Wed, Jul 3, 2013 at 3:04 PM, Eric Rescorla wrote: >> >>> On Wed, Jul 3, 2013 at 2:42 PM, I=C3=B1aki Baz Castillo = wrote: >>> >>>> So compatibility with SIP is important but compatibility with Jingle i= s >>>> just impossible. And this is supposed to be the API proposed to W3C... >>>> >>> Who said anything about impossible? It's a mechanical transformation >>> (see: http://xmpp.org/extensions/xep-0167.html). >>> >>> Anyway, it's not like this feature is a surprise to anyone--well at >>> least anyone who was paying attention--it's been a feature of the >>> specification since before the WG was even formed. As I said >>> earlier, it was in the original WHATWG spec that Ian Hickson >>> wrote. >>> >>> > >> There are lots of application developers who weren't around back then, >> so it's not reasonable to expect them to have been paying attention back >> then. Many are very new to this, and there are lots of surprises for th= em. >> > > The person I was responding to has posts on this mailing list going back > as far as September 2011. > > -Ekr > You said "it's not like this feature is a surprise to anyone", and I thought "anyone" was a bit broader than that. Sorry for the misunderstanding. --e89a8fb208343dbc9c04e0a2fc14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 3, 2013 at 3:20 PM, Eric Rescorla <= ;ekr@rtfm.com> wrote:



On Wed, Jul 3, 2013 at 3:16 PM, Peter Thatcher <ptha= tcher@google.com> wrote:



On Wed, Jul 3, 2013 at 3:04 PM, Eric Rescorla &= lt;ekr@rtfm.com> wrote:
On Wed, Jul 3, 2013 at 2:42 PM, I=C3= =B1aki Baz Castillo <ibc@aliax.net> wrote:

So compatibility with SIP is important but = compatibility with Jingle is just impossible. And this is supposed to be th= e API proposed to W3C...

Who said anything about impossible? It's a mech= anical transformation

Anyway, it's not like this feature is a surprise to anyone--well a= t
least anyone who was paying attention--it's been a feature = of the
specification since before the WG was even formed. As I sa= id
earlier, it was in the original WHATWG spec that Ian Hickson
wrote.

=C2=A0
=
There are lots of application developers who weren't around = back then, so it's not reasonable to expect them to have been paying at= tention back then. =C2=A0Many are very new to this, and there are lots of s= urprises for them.

The person I was respond= ing to has posts on this mailing list going back as far as September 2011.<= /div>

-Ekr

You said "it's n= ot like this feature is a surprise to anyone", =C2=A0and I thought &qu= ot;anyone" was a bit broader than that. =C2=A0Sorry for the misunderst= anding.

=C2=A0

--e89a8fb208343dbc9c04e0a2fc14-- From ekr@rtfm.com Wed Jul 3 15:34:50 2013 Return-Path: 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 BD14911E80E0 for ; Wed, 3 Jul 2013 15:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 uJBzsFEUb8l8 for ; Wed, 3 Jul 2013 15:34:45 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id C96DF21F9977 for ; Wed, 3 Jul 2013 15:34:44 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id nd7so431421qeb.33 for ; Wed, 03 Jul 2013 15:34:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Ln2s4RWeDYY2d/X0Acty1sEy82HER3f65ClJgHUzHi0=; b=YFjhWwt4geXOlXLcTgeRE6N9/rDCNo75EzouL2adkZWEYjluTwUVDqY55fOt9eNJMw 5VTGdhC404zfE+4MbeFfmJJGGZDq7cyqtzKrelp8402q1XA8q8Ax2CdJ7EqJYTWu6woW JIXmb/aspslNbsh2Eg+yqkO8D8SXYdXOy+NrVftXLRe94IsP5hFkARnj7fkIqTKF9QDb gWmEzfjc/A7+OZdnANlIJwiB8mzCKZTHArQH/XBcLm6vcmO4Hn+KXv/b5zJq5tuEvywr gNuojTG09cMXbKsArqSHHvpG2semXA7vKFm0eaYfs90BCqfm2V/F5E+wC4lcRYTr4fc8 gzLw== X-Received: by 10.49.35.233 with SMTP id l9mr3973840qej.23.1372890884304; Wed, 03 Jul 2013 15:34:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 3 Jul 2013 15:34:04 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 3 Jul 2013 15:34:04 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b671fa679852904e0a31164 X-Gm-Message-State: ALoCoQnhjzhEWHCL5JLEkEytvSoyt/bucVnJO9r7fPCpGn+8fqDZuGX7UqWzmZqhGEmU/MKEHz0N Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:34:50 -0000 --047d7b671fa679852904e0a31164 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 3:27 PM, Eric Rescorla wrote: > > > > On Wed, Jul 3, 2013 at 3:17 PM, I=F1aki Baz Castillo wrot= e: > >> 2013/7/4 Eric Rescorla : >> > Anyway, it's not like this feature is a surprise to anyone--well at >> > least anyone who was paying attention--it's been a feature of the >> > specification since before the WG was even formed. As I said >> > earlier, it was in the original WHATWG spec that Ian Hickson >> > wrote. >> >> I know, and I was a "SDP supporter" at the beginning (and much others >> like me who, after dealing with it for something more than just single >> audio+video phone calls, have changed their mind). > > > This leaves me puzzled by your complaint that the current specification > doesn't support Jingle out of the box, since that's been obvious from the > very beginning and it's not like that's something that required extensive > developer experience to discern. If this is important, why didn't you > complain then? > Looking back at your posts from back then, I see you did in fact suggest a set of API modifications that would have included an abstract session description. That would in fact have made Jingle somewhat (though not really that much) easier. So my last sentence here is unfair. My apologies. -Ekr --047d7b671fa679852904e0a31164 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 3, 2013 at 3:27 PM, Eric Rescorla <= ;ekr@rtfm.com> wrote:



On Wed, Jul 3, 201= 3 at 3:17 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2013/7/4 Eric Rescorla <ekr@rtfm.com>:
> Anyway, it's not like this feature is a surprise to anyone--w= ell at
> least anyone who was paying attention--it's been a feature of the<= br> > specification since before the WG was even formed. As I said
> earlier, it was in the original WHATWG spec that Ian Hickson
> wrote.

I know, and I was a =A0"SDP supporter" at the beginning (an= d much others
like me who, after dealing with it for something more than just single
audio+video phone calls, have changed their mind).=A0

=
This leaves me puzzled by your complaint that the cur= rent specification
doesn't support Jingle out of the box, sin= ce that's been obvious from the
very beginning and it's not like that's something that require= d extensive
developer experience to discern. If this is important= , why didn't you
complain then?

Looking back at your posts from back then,= I see you did in fact suggest
a set of API modifications t= hat would have included an abstract session
description. Th= at would in fact have made Jingle somewhat (though not
really that much) easier. So my last sentence here is unfair. My= apologies.

-Ekr

<= /div>
--047d7b671fa679852904e0a31164-- From fippo@goodadvice.pages.de Wed Jul 3 23:35:54 2013 Return-Path: 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 BE8BD21F96D5 for ; Wed, 3 Jul 2013 23:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 1JwQar7eEbB1 for ; Wed, 3 Jul 2013 23:35:50 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 467A821F8FAF for ; Wed, 3 Jul 2013 23:35:49 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r646ZlxA015791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2013 08:35:47 +0200 Received: from localhost (fippo@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) with ESMTP id r646ZkPe015787; Thu, 4 Jul 2013 08:35:46 +0200 X-Authentication-Warning: lo.psyced.org: fippo owned process doing -bs Date: Thu, 4 Jul 2013 08:35:46 +0200 (CEST) From: Philipp Hancke X-X-Sender: fippo@lo.psyced.org To: Eric Rescorla In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="683466026-978727032-1372919747=:14960" Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 06:35:54 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --683466026-978727032-1372919747=:14960 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 3 Jul 2013, Eric Rescorla wrote: > Who said anything about impossible? It's a mechanical transformation > (see: http://xmpp.org/extensions/xep-0167.html). That is true for simple usage and works reasonably well. See my strophe.jingle code on github. I'd note that I want to revamp the API such that it wraps the peerconnections SDP apis more closely. Things like the content-add/content-remove are harder because the API user is required to calculate an SDP delta/diff. The appendix A.1.3 of the JSEP draft calls this createContentAdd, parseContentAdd, createContentAccept and parseContentAccept. Has anyone ever implemented those operations in javascript and can demonstrate running code? --683466026-978727032-1372919747=:14960-- From ibc@aliax.net Thu Jul 4 01:21:33 2013 Return-Path: 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 6990821F9F55 for ; Thu, 4 Jul 2013 01:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 CrKgAc-idYSg for ; Thu, 4 Jul 2013 01:21:28 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4F36B21F9EF0 for ; Thu, 4 Jul 2013 01:21:27 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id g10so647899qah.12 for ; Thu, 04 Jul 2013 01:21:26 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=kJLj/hRd1XkQ02jTGVXTO0ZjslAtIOyPo6+xDM0xZiE=; b=Eo/2Z0X5YX9iNKc9mpmf4KZ6YEV/iS+Nrr1FT1/HFTwpGuP4sV/QykWAH1NYndPNDf F6F9RDS025hX3JPpsv9gaojDJHUyaVlwR6MNTahZdQj/aQV1GzlFXsCfpZkwcO5llPGn C9tRo7j5RmrQgrqctz9Wr88ZXpMIkJuLx4jNOUEoStvng98C0p8+mR0SBTcJN3DHW4Jt 1CXHpkgBt/+/rbCIE+0zIZYDYFjkMB6QRdMUUJBZC05T3JU8gNGvnUOXGHUaV3ibDde6 6sArI6doQudS0I/dZqJPi2eMejbFv3Il6xPu2UiHuW2a0vnP2Dk6++LRQz/vigxqu6GB bcBA== X-Received: by 10.229.206.2 with SMTP id fs2mr1035534qcb.68.1372926086607; Thu, 04 Jul 2013 01:21:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Thu, 4 Jul 2013 01:21:06 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 4 Jul 2013 10:21:06 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk7cGuWM263JrnAZXkGIW7JGDCJVNzqmvQB/VY21d3BfEBKv0T8UoGeEdlV++cFfDTPXKXY Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 08:21:33 -0000 2013/7/4 Eric Rescorla : > Looking back at your posts from back then, I see you did in fact suggest > a set of API modifications that would have included an abstract session > description. That would in fact have made Jingle somewhat (though not > really that much) easier. So my last sentence here is unfair. My apologie= s. Initially I though that SessionDescription was a powerful JS Object with all the fields and attributes to construct a SDP, so a developer could extract those media/transport fields and create a SDP via JS. At the same time, the SessionDescription object would include helper methods (defined by the WebRTC API) to build a plain SDP (i.e. toSDP) and some others like XML-SDP (i.e. toXMLSDP). -- I=C3=B1aki Baz Castillo From binod.pg@oracle.com Thu Jul 4 02:10:45 2013 Return-Path: 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 89ED221F9F53 for ; Thu, 4 Jul 2013 02:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Fjg8S4dFqUyD for ; Thu, 4 Jul 2013 02:10:39 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D0BB821F9F4F for ; Thu, 4 Jul 2013 02:10:39 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r649AcO3030368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 4 Jul 2013 09:10:39 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r649AbSq002799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Jul 2013 09:10:38 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r649Ab1U002791 for ; Thu, 4 Jul 2013 09:10:37 GMT Received: from [10.159.253.40] (/10.159.253.40) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Jul 2013 02:10:37 -0700 Message-ID: <51D53C07.6040402@oracle.com> Date: Thu, 04 Jul 2013 14:40:31 +0530 From: Binod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 09:10:45 -0000 On Thursday 04 July 2013 01:51 PM, Iñaki Baz Castillo wrote: > 2013/7/4 Eric Rescorla : >> Looking back at your posts from back then, I see you did in fact suggest >> a set of API modifications that would have included an abstract session >> description. That would in fact have made Jingle somewhat (though not >> really that much) easier. So my last sentence here is unfair. My apologies. > Initially I though that SessionDescription was a powerful JS Object > with all the fields and attributes to construct a SDP, so a developer > could extract those media/transport fields and create a SDP via JS. At > the same time, the SessionDescription object would include helper > methods (defined by the WebRTC API) to build a plain SDP (i.e. toSDP) > and some others like XML-SDP (i.e. toXMLSDP). I like that approach. Have an API to specify all/most of what is in the SDP and then use a toSDP to generate actual SDP string to be sent across the wire. Other side should be able to reconstruct the browser side object(s) using the received SDP string. thanks, Binod. > > > > -- > Iñaki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From robin@hookflash.com Thu Jul 4 04:33:00 2013 Return-Path: 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 3C3AA21F9EB3 for ; Thu, 4 Jul 2013 04:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 7AOEraLyF1yE for ; Thu, 4 Jul 2013 04:32:55 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF7A21F9E79 for ; Thu, 4 Jul 2013 04:32:55 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so3020576iec.27 for ; Thu, 04 Jul 2013 04:32:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=lhjjkgnHPe0iGZp7bJ9gg1eN4G3ehCGWm2xDEvnSZtU=; b=jrxlLFxCaIPuTeO1Sh5IfBluFqVKPx9pd7ht+wHcY5910crFyXixd/RjyZQKdAIhKp oUhSjVwWhLsg55D6R8Px68UQGEUCx5lKiKtpl2riZ7TqERGklxs73PPDvl9AKz+mb940 ioD/gCnYeUWgknFeCp5TrZs8C72nL9Ziqfgi+L+6BqNC2BwGw5E19nsB6hvd2wPjGyoi xWnYS2ik536fn86k4xbCMYOso0lkCEhxittoCXb/cQhgoVKLAruE7pwpBzcJkcJBVKIt p8xQCb6dHSy9vr0AfebirPJAPKs77AHqjbepfn7GPYeDUiBYSRfrAHpMoiO2hBLbD+jt 9onQ== X-Received: by 10.50.3.42 with SMTP id 10mr26633244igz.39.1372937573998; Thu, 04 Jul 2013 04:32:53 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id vc13sm1546103igb.1.2013.07.04.04.32.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Jul 2013 04:32:53 -0700 (PDT) Message-ID: <51D55D62.7090608@hookflash.com> Date: Thu, 04 Jul 2013 07:32:50 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Binod References: <51D53C07.6040402@oracle.com> In-Reply-To: <51D53C07.6040402@oracle.com> Content-Type: multipart/alternative; boundary="------------030309080505080209080703" X-Gm-Message-State: ALoCoQlR7YnpsIjDjdc6MmGqMAQR9v9YTf8pixMxHONLsb+GxohXwE9W13SiI4aZ8aPoazIbNwGD Cc: rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 11:33:00 -0000 This is a multi-part message in MIME format. --------------030309080505080209080703 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit +1 on object model with a "toSDP / fromSDP" (FYI - an object model draft is looming shortly) I think it's best to put "toSDP / fromSDP" outside the browser binary as a common github JS library because I know a lot of SIP folks love custom SDP extensions and being able to fork/tweak the SDP without petitioning the browser vendors for an "update" is important. -Robin > Binod > 4 July, 2013 5:10 AM > On Thursday 04 July 2013 01:51 PM, Iñaki Baz Castillo wrote: >> 2013/7/4 Eric Rescorla : >>> Looking back at your posts from back then, I see you did in fact >>> suggest >>> a set of API modifications that would have included an abstract session >>> description. That would in fact have made Jingle somewhat (though not >>> really that much) easier. So my last sentence here is unfair. My >>> apologies. >> Initially I though that SessionDescription was a powerful JS Object >> with all the fields and attributes to construct a SDP, so a developer >> could extract those media/transport fields and create a SDP via JS. At >> the same time, the SessionDescription object would include helper >> methods (defined by the WebRTC API) to build a plain SDP (i.e. toSDP) >> and some others like XML-SDP (i.e. toXMLSDP). > I like that approach. Have an API to specify all/most of what is > in the SDP and then use a toSDP to generate actual SDP string to be sent > across the wire. > > Other side should be able to reconstruct the browser side > object(s) using the received SDP string. > > thanks, > Binod. --------------030309080505080209080703 Content-Type: multipart/related; boundary="------------020205090909020408000200" --------------020205090909020408000200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
+1 on object model with a "toSDP / fromSDP"  (FYI - an object model draft is looming shortly)

I think it's best to put "toSDP / fromSDP" outside the browser binary as a common github JS library because I know a lot of SIP folks love custom SDP extensions and being able to fork/tweak the SDP without petitioning the browser vendors for an "update" is important.

-Robin
4 July, 2013 5:10 AM
On Thursday 04 July 2013 01:51 PM, Iñaki Baz Castillo wrote:
2013/7/4 Eric Rescorla <ekr@rtfm.com>:
Looking back at your posts from back then, I see you did in fact suggest
a set of API modifications that would have included an abstract session
description. That would in fact have made Jingle somewhat (though not
really that much) easier. So my last sentence here is unfair. My apologies.
Initially I though that SessionDescription was a powerful JS Object
with all the fields and attributes to construct a SDP, so a developer
could extract those media/transport fields and create a SDP via JS. At
the same time, the SessionDescription object would include helper
methods (defined by the WebRTC API) to build a plain SDP (i.e. toSDP)
and some others like XML-SDP (i.e. toXMLSDP).
I like that approach. Have an API to specify all/most of what is
in the SDP and then use a toSDP to generate actual SDP string to be sent
across the wire.

Other side should be able to reconstruct the browser side
object(s) using the received SDP string.

thanks,
Binod.
--------------020205090909020408000200 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------020205090909020408000200-- --------------030309080505080209080703-- From matthew@matthew.at Thu Jul 4 08:03:58 2013 Return-Path: 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 4E1D311E8134 for ; Thu, 4 Jul 2013 08:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MIME_QP_LONG_LINE=1.396] 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 5-6MH6Bb9JDN for ; Thu, 4 Jul 2013 08:03:54 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E43711E812A for ; Thu, 4 Jul 2013 08:03:54 -0700 (PDT) Received: from [10.10.155.233] (unknown [10.10.155.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 4ACD8250041; Thu, 4 Jul 2013 08:03:47 -0700 (PDT) References: <51D53C07.6040402@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: <51D53C07.6040402@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <42509D1B-2807-4611-BA25-416DE0C25EB9@matthew.at> X-Mailer: iPhone Mail (10B146) From: Matthew Kaufman Date: Thu, 4 Jul 2013 08:03:45 -0700 To: Binod Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:03:58 -0000 You will still be required to wrestle the browser's offer-answer state machi= ne into submission to get the results you want. Matthew Kaufman (Sent from my iPhone) On Jul 4, 2013, at 2:10 AM, Binod wrote: > On Thursday 04 July 2013 01:51 PM, I=C3=B1aki Baz Castillo wrote: >> 2013/7/4 Eric Rescorla : >>> Looking back at your posts from back then, I see you did in fact suggest= >>> a set of API modifications that would have included an abstract session >>> description. That would in fact have made Jingle somewhat (though not >>> really that much) easier. So my last sentence here is unfair. My apologi= es. >> Initially I though that SessionDescription was a powerful JS Object >> with all the fields and attributes to construct a SDP, so a developer >> could extract those media/transport fields and create a SDP via JS. At >> the same time, the SessionDescription object would include helper >> methods (defined by the WebRTC API) to build a plain SDP (i.e. toSDP) >> and some others like XML-SDP (i.e. toXMLSDP). > I like that approach. Have an API to specify all/most of what is > in the SDP and then use a toSDP to generate actual SDP string to be sent > across the wire. >=20 > Other side should be able to reconstruct the browser side > object(s) using the received SDP string. >=20 > thanks, > Binod. >>=20 >>=20 >>=20 >> -- >> I=C3=B1aki Baz Castillo >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Thu Jul 4 17:47:32 2013 Return-Path: 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 DCAFD11E821B for ; Thu, 4 Jul 2013 17:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 llgaeUR-jAjp for ; Thu, 4 Jul 2013 17:47:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 09E6111E80F9 for ; Thu, 4 Jul 2013 17:47:26 -0700 (PDT) Received: from [10.0.0.15] (unknown [71.198.222.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 67D3822E255 for ; Thu, 4 Jul 2013 20:47:20 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> Date: Thu, 4 Jul 2013 17:47:20 -0700 To: "rtcweb@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 00:47:33 -0000 As part of putting together some chair slides for Berlin, I'm trying to = get a very rough idea of where things are. I'd like to get folks input = on what percent done various drafts are where Done is a published RFC.=20= This is nearly impossible to do at any level of accuracy but I do want = to get a vague idea. I took a very rough stab below just to have a = starting point to get the conversation going. I'm sure my numbers are = mostly wrong but I have tried to ask a few people and sort of take the = central cluster of the guess. If you think I am way out, please provide = some feedback of what you think the number actually is. I'm happy to get feedback on specific drafts or feedback of the form = they are all too low or too high. I do encourage people to realistically = look at the data tracker to see how long other drafts have taken for = each stage to get a baseline instead of just going with their gut feel.=20= Thanks, Cullen PS - if you are an author and look at the number next to your draft and = think it is way off, please please, say something.=20 draft-ietf-rtcweb-overview 80 draft-ietf-rtcweb-use-cases-and-requirements 70 http://dev.w3.org/2011/webrtc/editor/getusermedia.html 70 draft-burnett-rtcweb-constraints-registry 80 http://dev.w3.org/2011/webrtc/editor/webrtc.html 50 draft-nandakumar-rtcweb-stun-uri 80 draft-petithuguenin-behave-turn-uris 80 draft-ietf-rtcweb-security 80 draft-ietf-rtcweb-security-arch 80 draft-muthu-behave-consent-freshness-02 50 draft-ietf-rtcweb-data-channel 70 draft-ietf-mmusic-sctp-sdp 70 draft-jesup-rtcweb-data-protocol 50 draft-ietf-tsvwg-sctp-dtls-encaps 70 draft-ietf-rtcweb-rtp-usage 40 draft-ietf-avtcore-6222bis 80 draft-ietf-avtcore-avp-codecs 80 draft-ietf-avtcore-srtp-encrypted-header-ext 80 draft-ietf-avtext-multiple-clock-rates 70 draft-lennox-rtcweb-rtp-media-type-mux 80 draft-ietf-avtcore-rtp-circuit-breakers 70 draft-ietf-avtcore-multi-media-rtp-session 70 draft-lennox-avtcore-rtp-multi-stream 70 draft-ietf-rtcweb-jsep 50 draft-ietf-mmusic-msid 70 draft-rescorla-mmusic-ice-trickle 25 draft-ietf-mmusic-sdp-bundle-negotiation 50 draft-nandakumar-mmusic-sdp-mux-attributes 25 draft-dhesikan-tsvwg-rtcweb-qos 10 or 90 draft-ietf-rtcweb-audio 50 draft-ietf-payload-rtp-opus 90 draft-ietf-payload-vp8-08 95 From jonathan@vidyo.com Fri Jul 5 09:29:49 2013 Return-Path: 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 51DBB21F9CD1 for ; Fri, 5 Jul 2013 09:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 oHMA+9nrywti for ; Fri, 5 Jul 2013 09:29:44 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 42DFE21F9CE6 for ; Fri, 5 Jul 2013 09:29:44 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B94797A95FF; Fri, 5 Jul 2013 12:29:42 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 66C457A94F5; Fri, 5 Jul 2013 12:29:42 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Fri, 5 Jul 2013 12:28:54 -0400 From: Jonathan Lennox To: Cullen Jennings Date: Fri, 5 Jul 2013 12:29:41 -0400 Thread-Topic: [rtcweb] Question about the status of various drafts Thread-Index: Ac55nL3KXcZAoKjNQEqMhoOCj/++qg== Message-ID: References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> In-Reply-To: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 16:29:49 -0000 On Jul 4, 2013, at 8:47 PM, Cullen Jennings wrote: > draft-ietf-avtcore-srtp-encrypted-header-ext 80 RFC 6904 - done. (Your estimates for the other drafts I'm working on seem reasonable.) -- Jonathan Lennox jonathan@vidyo.com From mperumal@cisco.com Fri Jul 5 10:12:28 2013 Return-Path: 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 B4A0A21F9E43 for ; Fri, 5 Jul 2013 10:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 RCyS+TFsxI5N for ; Fri, 5 Jul 2013 10:12:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DAA1021F9CED for ; Fri, 5 Jul 2013 10:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2963; q=dns/txt; s=iport; t=1373044344; x=1374253944; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mK2gux+5T19xNkn5627QTGhMAvEZHTmzEXpsFkPMk7g=; b=bExolzB+z/oRvMT8ZzxIurmK9dseO92NxMovtfmLHYHrJagTDlPjOweJ WJi2XBsWKok2bUU0JHlO/gp/cQAyWGdb+Tby2NlZ68TUDCcEZ1Mo98qk7 Gx+Ko/8fd4I5vZO6qHaZ+m2az6ycspFfzNnllvm0LKclmV3zn1kUdjaRj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANb81lGtJV2c/2dsb2JhbABagwkyScBBgQEWdIIjAQEBBAEBATc0BhEEAgEIDgMEAQELFAkHJwsUCQgCBAESCIgHDLh8jzozBQaCfmkDqQ6DEYIo X-IronPort-AV: E=Sophos;i="4.87,1003,1363132800"; d="scan'208";a="231369313" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 05 Jul 2013 17:12:23 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r65HCMpD024007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 17:12:22 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 12:12:22 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Cullen Jennings , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Question about the status of various drafts Thread-Index: AQHOeRk/tudr66K7zkWNqe1owheDIJlWUhGw Date: Fri, 5 Jul 2013 17:12:21 +0000 Message-ID: References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> In-Reply-To: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.32.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 17:12:28 -0000 Hi Cullen, |draft-muthu-behave-consent-freshness-02 50 Reasonable assessment. We are working on the next revision. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f Cullen Jennings |Sent: Friday, July 05, 2013 6:17 AM |To: rtcweb@ietf.org |Subject: [rtcweb] Question about the status of various drafts | | |As part of putting together some chair slides for Berlin, I'm trying to ge= t a very rough idea of where |things are. I'd like to get folks input on what percent done various draft= s are where Done is a |published RFC. | |This is nearly impossible to do at any level of accuracy but I do want to = get a vague idea. I took a |very rough stab below just to have a starting point to get the conversatio= n going. I'm sure my numbers |are mostly wrong but I have tried to ask a few people and sort of take the= central cluster of the |guess. If you think I am way out, please provide some feedback of what you= think the number actually |is. | |I'm happy to get feedback on specific drafts or feedback of the form they = are all too low or too high. |I do encourage people to realistically look at the data tracker to see how= long other drafts have |taken for each stage to get a baseline instead of just going with their gu= t feel. | |Thanks, Cullen | |PS - if you are an author and look at the number next to your draft and th= ink it is way off, please |please, say something. | | | |draft-ietf-rtcweb-overview 80 |draft-ietf-rtcweb-use-cases-and-requirements 70 |http://dev.w3.org/2011/webrtc/editor/getusermedia.html 70 |draft-burnett-rtcweb-constraints-registry 80 |http://dev.w3.org/2011/webrtc/editor/webrtc.html 50 |draft-nandakumar-rtcweb-stun-uri 80 |draft-petithuguenin-behave-turn-uris 80 |draft-ietf-rtcweb-security 80 |draft-ietf-rtcweb-security-arch 80 |draft-muthu-behave-consent-freshness-02 50 |draft-ietf-rtcweb-data-channel 70 |draft-ietf-mmusic-sctp-sdp 70 |draft-jesup-rtcweb-data-protocol 50 |draft-ietf-tsvwg-sctp-dtls-encaps 70 |draft-ietf-rtcweb-rtp-usage 40 |draft-ietf-avtcore-6222bis 80 |draft-ietf-avtcore-avp-codecs 80 |draft-ietf-avtcore-srtp-encrypted-header-ext 80 |draft-ietf-avtext-multiple-clock-rates 70 |draft-lennox-rtcweb-rtp-media-type-mux 80 |draft-ietf-avtcore-rtp-circuit-breakers 70 |draft-ietf-avtcore-multi-media-rtp-session 70 |draft-lennox-avtcore-rtp-multi-stream 70 |draft-ietf-rtcweb-jsep 50 |draft-ietf-mmusic-msid 70 |draft-rescorla-mmusic-ice-trickle 25 |draft-ietf-mmusic-sdp-bundle-negotiation 50 |draft-nandakumar-mmusic-sdp-mux-attributes 25 |draft-dhesikan-tsvwg-rtcweb-qos 10 or 90 |draft-ietf-rtcweb-audio 50 |draft-ietf-payload-rtp-opus 90 |draft-ietf-payload-vp8-08 95 | | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Fri Jul 5 14:25:41 2013 Return-Path: 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 304D821F9DB0 for ; Fri, 5 Jul 2013 14:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 1paR+Bz8NtQe for ; Fri, 5 Jul 2013 14:25:36 -0700 (PDT) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA1421F9D3A for ; Fri, 5 Jul 2013 14:25:27 -0700 (PDT) Received: from BLU169-W82 ([65.55.116.74]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Jul 2013 14:25:26 -0700 X-TMN: [oY5eGw5o1kwzv87IMFCDEnXpK5v65qPm] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_136c9421-69b9-4aa7-a3f6-ebcdda05f936_" From: Bernard Aboba To: Cullen Jennings , "rtcweb@ietf.org" Date: Fri, 5 Jul 2013 14:25:26 -0700 Importance: Normal In-Reply-To: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jul 2013 21:25:26.0820 (UTC) FILETIME=[2AC28640:01CE79C6] Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 21:25:41 -0000 --_136c9421-69b9-4aa7-a3f6-ebcdda05f936_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think you need to take dependencies into account. There are several rea= sons for this:=20 a. Until you've gone through the dependency graph for the items=2C the f= ull list of documents that need to be tracked isn't known. b. Estimates = of completion are dependent on the progress of normative dependencies (e.g.= they can't be published until the dependencies are resolved).=20 As an example=2C draft-ietf-rtcweb-overview (which is listed as 80 percent= complete) has normative references to the following drafts:=20 [I-D.ietf-mmusic-sctp-sdp] 70 [I-D.ietf-rtcweb-audio] 50 [I-D.ietf-r= tcweb-data-channel] 70 [I-D.ietf-rtcweb-jsep] 50 [I-D.ietf-rtcweb-rtp-u= sage] 40 [I-D.ietf-rtcweb-security] 80 [I-D.ietf-rtcweb-security-arch] = 80 [I-D.nandakumar-rtcweb-stun-uri] 80 [I-D.tuexen-tsvwg-sctp-dtls-enca= ps] 70 Since draft-ietf-rtcweb-overview is dependent on a docume= nt (rtp usage) which only has an estimate of 40 percent done) I'd say that = the estimate is probably closer to 40 than 80.=20 > From: fluffy@iii.ca > Date: Thu=2C 4 Jul 2013 17:47:20 -0700 > To: rtcweb@ietf.org > Subject: [rtcweb] Question about the status of various drafts >=20 >=20 > As part of putting together some chair slides for Berlin=2C I'm trying to= get a very rough idea of where things are. I'd like to get folks input on = what percent done various drafts are where Done is a published RFC.=20 >=20 > This is nearly impossible to do at any level of accuracy but I do want to= get a vague idea. I took a very rough stab below just to have a starting p= oint to get the conversation going. I'm sure my numbers are mostly wrong bu= t I have tried to ask a few people and sort of take the central cluster of = the guess. If you think I am way out=2C please provide some feedback of wha= t you think the number actually is. >=20 > I'm happy to get feedback on specific drafts or feedback of the form they= are all too low or too high. I do encourage people to realistically look a= t the data tracker to see how long other drafts have taken for each stage t= o get a baseline instead of just going with their gut feel.=20 >=20 > Thanks=2C Cullen >=20 > PS - if you are an author and look at the number next to your draft and t= hink it is way off=2C please please=2C say something.=20 >=20 >=20 >=20 > draft-ietf-rtcweb-overview 80 > draft-ietf-rtcweb-use-cases-and-requirements 70 > http://dev.w3.org/2011/webrtc/editor/getusermedia.html 70 > draft-burnett-rtcweb-constraints-registry 80 > http://dev.w3.org/2011/webrtc/editor/webrtc.html 50 > draft-nandakumar-rtcweb-stun-uri 80 > draft-petithuguenin-behave-turn-uris 80 > draft-ietf-rtcweb-security 80 > draft-ietf-rtcweb-security-arch 80 > draft-muthu-behave-consent-freshness-02 50 > draft-ietf-rtcweb-data-channel 70 > draft-ietf-mmusic-sctp-sdp 70 > draft-jesup-rtcweb-data-protocol 50 > draft-ietf-tsvwg-sctp-dtls-encaps 70 > draft-ietf-rtcweb-rtp-usage 40 > draft-ietf-avtcore-6222bis 80 > draft-ietf-avtcore-avp-codecs 80 > draft-ietf-avtcore-srtp-encrypted-header-ext 80 > draft-ietf-avtext-multiple-clock-rates 70 > draft-lennox-rtcweb-rtp-media-type-mux 80 > draft-ietf-avtcore-rtp-circuit-breakers 70 > draft-ietf-avtcore-multi-media-rtp-session 70 > draft-lennox-avtcore-rtp-multi-stream 70 > draft-ietf-rtcweb-jsep 50 > draft-ietf-mmusic-msid 70 > draft-rescorla-mmusic-ice-trickle 25 > draft-ietf-mmusic-sdp-bundle-negotiation 50 > draft-nandakumar-mmusic-sdp-mux-attributes 25 > draft-dhesikan-tsvwg-rtcweb-qos 10 or 90 > draft-ietf-rtcweb-audio 50 > draft-ietf-payload-rtp-opus 90 > draft-ietf-payload-vp8-08 95 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --_136c9421-69b9-4aa7-a3f6-ebcdda05f936_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think you need to take depende= ncies into account.  =3B There are several reasons for this: =3B
 =3B  =3Ba. Until you've gone through the dependency gra= ph for the items=2C the full list of documents that need to be tracked isn'= t known. =3B
 =3B  =3Bb. Estimates of completion are = dependent on the progress of normative dependencies (e.g. they can't be pub= lished until the dependencies are resolved). =3B

As an example=2C  =3Bdraft-ietf-rtcweb-overview (which is listed as 80= percent complete) has normative references to the following drafts: = =3B

 =3B  =3B[I-D.ietf-mmusic-sctp-sdp] 70<= /div>
 =3B  =3B[I-D.ietf-rtcweb-audio] 50
 =3B &n= bsp=3B[I-D.ietf-rtcweb-data-channel] 70
 =3B  =3B[I-D.iet= f-rtcweb-jsep] 50
 =3B  =3B[I-D.ietf-rtcweb-rtp-usage] 40=
 =3B  =3B[I-D.ietf-rtcweb-security] 80
 = =3B  =3B[I-D.ietf-rtcweb-security-arch] 80
 =3B  =3B[= I-D.nandakumar-rtcweb-stun-uri] 80
 =3B  =3B[I-D.tuexen-t= svwg-sctp-dtls-encaps] 70
 =3B  =3B  =3B  =3B &nb= sp=3B  =3B =3B
Since draft-ietf-rtcweb-overview is depend= ent on a document (rtp usage) which only has an estimate of 40 percent done= ) I'd say that the estimate is probably closer to 40 than 80. =3B
=


>=3B From: fluffy@iii.ca
>=3B Date: Thu= =2C 4 Jul 2013 17:47:20 -0700
>=3B To: rtcweb@ietf.org
>=3B Subje= ct: [rtcweb] Question about the status of various drafts
>=3B
>= =3B
>=3B As part of putting together some chair slides for Berlin=2C = I'm trying to get a very rough idea of where things are. I'd like to get fo= lks input on what percent done various drafts are where Done is a published= RFC.
>=3B
>=3B This is nearly impossible to do at any level of= accuracy but I do want to get a vague idea. I took a very rough stab below= just to have a starting point to get the conversation going. I'm sure my n= umbers are mostly wrong but I have tried to ask a few people and sort of ta= ke the central cluster of the guess. If you think I am way out=2C please pr= ovide some feedback of what you think the number actually is.
>=3B >=3B I'm happy to get feedback on specific drafts or feedback of the for= m they are all too low or too high. I do encourage people to realistically = look at the data tracker to see how long other drafts have taken for each s= tage to get a baseline instead of just going with their gut feel.
>= =3B
>=3B Thanks=2C Cullen
>=3B
>=3B PS - if you are an aut= hor and look at the number next to your draft and think it is way off=2C pl= ease please=2C say something.
>=3B
>=3B
>=3B
>=3B d= raft-ietf-rtcweb-overview 80
>=3B draft-ietf-rtcweb-use-cases-and-req= uirements 70
>=3B http://dev.w3.org/2011/webrtc/editor/getusermedia.ht= ml 70
>=3B draft-burnett-rtcweb-constraints-registry 80
>=3B htt= p://dev.w3.org/2011/webrtc/editor/webrtc.html 50
>=3B draft-nandakumar= -rtcweb-stun-uri 80
>=3B draft-petithuguenin-behave-turn-uris 80
= >=3B draft-ietf-rtcweb-security 80
>=3B draft-ietf-rtcweb-security-= arch 80
>=3B draft-muthu-behave-consent-freshness-02 50
>=3B dr= aft-ietf-rtcweb-data-channel 70
>=3B draft-ietf-mmusic-sctp-sdp 70>=3B draft-jesup-rtcweb-data-protocol 50
>=3B draft-ietf-tsvwg-s= ctp-dtls-encaps 70
>=3B draft-ietf-rtcweb-rtp-usage 40
>=3B dra= ft-ietf-avtcore-6222bis 80
>=3B draft-ietf-avtcore-avp-codecs 80
= >=3B draft-ietf-avtcore-srtp-encrypted-header-ext 80
>=3B draft-ietf= -avtext-multiple-clock-rates 70
>=3B draft-lennox-rtcweb-rtp-media-ty= pe-mux 80
>=3B draft-ietf-avtcore-rtp-circuit-breakers 70
>=3B= draft-ietf-avtcore-multi-media-rtp-session 70
>=3B draft-lennox-avtc= ore-rtp-multi-stream 70
>=3B draft-ietf-rtcweb-jsep 50
>=3B dra= ft-ietf-mmusic-msid 70
>=3B draft-rescorla-mmusic-ice-trickle 25
= >=3B draft-ietf-mmusic-sdp-bundle-negotiation 50
>=3B draft-nandakum= ar-mmusic-sdp-mux-attributes 25
>=3B draft-dhesikan-tsvwg-rtcweb-qos = 10 or 90
>=3B draft-ietf-rtcweb-audio 50
>=3B draft-ietf-payload= -rtp-opus 90
>=3B draft-ietf-payload-vp8-08 95
>=3B
>=3B =
>=3B _______________________________________________
>=3B rtcweb= mailing list
>=3B rtcweb@ietf.org
>=3B https://www.ietf.org/mail= man/listinfo/rtcweb
= --_136c9421-69b9-4aa7-a3f6-ebcdda05f936_-- From stefan.lk.hakansson@ericsson.com Fri Jul 5 23:34:07 2013 Return-Path: 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 89F4E21F9CD0 for ; Fri, 5 Jul 2013 23:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 xNTcdOINmkUv for ; Fri, 5 Jul 2013 23:34:01 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D640221F9CC2 for ; Fri, 5 Jul 2013 23:34:00 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-11-51d7ba56fe3e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 94.3B.19388.65AB7D15; Sat, 6 Jul 2013 08:33:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Sat, 6 Jul 2013 08:33:57 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Eric Rescorla Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOeDFbTNRhHYI3NkSZeqhrbqmeQg== Date: Sat, 6 Jul 2013 06:33:57 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW7YruuBBpsf81useH2O3eLa8tes Fmv/tbM7MHss2FTqsWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgyzh94z1pwQ6xi4/NnjA2M dwS6GDk5JARMJC5evcIKYYtJXLi3nq2LkYtDSOAwo8SqfYtYIZyFjBILJixlBqliEwiU2Lpv ARuILSKgIPHrzwkWEJtZIEhi7q5nTCC2sECVxPLDx9i7GDmAaqollvSXQ5TrSXRd3ApWziKg ItGz/wUjiM0r4Cvxee8iFohdS5kk7q6/ww6SYAS66PupNUwQ88Ulbj2ZzwRxqYDEkj3nmSFs UYmXj/9BfaAk8WPDJah79CRuTJ3CBmFrSyxb+JoZYpmgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsoqRPTcxMye93HwTIzA+Dm75bbCDcdN9sUOM0hwsSuK8m/XOBAoJpCeWpGanphakFsUX leakFh9iZOLglGpgXKFfYSjDZmUgyHg+pOXvLo0Nqezl2/Qs1/JzpJit49n7l4tnQ+mrk0++ XNJlXnu0wmzJml+LW/sr1Is4hHUuhwofel57a1XmmYxaE9H5if8XaU1m0PjQOPPcrcrgZPaK zWdum5yNU4ndFSrutu9Rg82Ul/1F26bob/qgu2DVf8+Lq1ot2fZnKLEUZyQaajEXFScCAGbl q+RdAgAA Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 06:34:07 -0000 On 7/3/13 11:37 PM, Eric Rescorla wrote:=0A= > On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher > wrote:=0A= >=0A= > On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla > wrote:=0A= >=0A= > On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher=0A= > > wrote:=0A= >=0A= > Camp #0: I've used SDP for years and I'm very comfortable=0A= > with it. Using SDP as the control surface really helps my=0A= > use case, which is legacy interop. Defining an API without= =0A= > SDP would be too much work, and probably fail. Look at what= =0A= > happened with SDPng! Supporting all these advanced use=0A= > cases doesn't seem worth it. If developers are doing that= =0A= > much advanced stuff, they can learn to munge SDP. It isn't= =0A= > that bad.=0A= >=0A= >=0A= > Hmm... That's not my understanding of the situation at all.=0A= >=0A= > Rather, I believe the expectation is that you shouldn't have to= =0A= > modify the=0A= > SDP but rather there should be API points to cover most of the=0A= > use cases=0A= > that people want. This isn't to say that all those API points=0A= > exist or that=0A= > they work or whatever.=0A= >=0A= > -Ekr=0A= >=0A= >=0A= > I'm glad to be wrong here. Is the phrase "you shouldn't have to=0A= > modify the SDP but rather there should be API points to cover most=0A= > of the use cases" the consensus of the working group?=0A= >=0A= >=0A= > I thought it was, but I'm not the chair, so maybe you could ask Harald or= =0A= > Stefan.=0A= =0A= I definitely think this is the consensus of the working group.=0A= =0A= I think the exception would be when interoperating with other systems =0A= that use another dialect of SDP - I don't think we could cover such =0A= translations with API points.=0A= =0A= =0A= >=0A= >=0A= > Along with that, is "use Jingle for signalling" included in your set= =0A= > of "most of the use cases"?=0A= >=0A= >=0A= > No, I don't think it is, since it's not SDP.=0A= >=0A= > Maybe I could phrase this differently: It was my understanding that you= =0A= > should have=0A= > API points to get the PC to emit SDP that would express the policies,=0A= > preferences,=0A= > actions, etc. that the application wants. If you want something that's=0A= > not SDP you would=0A= > need to gateway.=0A= >=0A= > This may or may not be a satisfactory state of affairs, but it was the=0A= > rule I was using=0A= > (based on what I thought the WG expected) for when use cases needed new A= PI=0A= > points.=0A= >=0A= > -Ekr=0A= >=0A= =0A= From silviapfeiffer1@gmail.com Sat Jul 6 04:00:10 2013 Return-Path: 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 4F22821F8B33 for ; Sat, 6 Jul 2013 04:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Uj5iAT8oW0ua for ; Sat, 6 Jul 2013 04:00:09 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BAC6821F8A85 for ; Sat, 6 Jul 2013 04:00:09 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id m1so4396280oag.20 for ; Sat, 06 Jul 2013 04:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kLQaObYiaumQ1khfnpnbGh53cauk97Ir/kReU8Sw+rU=; b=BW42HfsdbUBj5e1zpQjpL21CeDZ0y9im5ZOXDQiAb+FzZ8CKjAHYusU0kmPO8kTUzL a9s/r4lTgLAboJgbbbqJcatcuq1gLIWBRRlv27S8689GYNsF4UqQAGm1SDDDhqS3Gw0W 3klSG1KgoYGeeKopymINcB4/uvt9swy4fK5+29rl8qwqKRfG/mvVJyk6ke8k2YRfw2vR 0MJHc47uhTa9rxVZFuxIZQSJq6F71B1nkE32BA6fcwDAy+Az2ca+uHNasPdJO0BBeYZf /IZV4NnzkmxbTmtf482ty1IMP399opiHOOrqNtm/k9oQ7DnFtNkt1kRM1eXVqG2YojZD 9fkw== X-Received: by 10.182.118.129 with SMTP id km1mr15014578obb.15.1373108409308; Sat, 06 Jul 2013 04:00:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.173.106 with HTTP; Sat, 6 Jul 2013 03:59:49 -0700 (PDT) In-Reply-To: <51CA6FEE.6030702@hookflash.com> References: <51CA6FEE.6030702@hookflash.com> From: Silvia Pfeiffer Date: Sat, 6 Jul 2013 20:59:49 +1000 Message-ID: To: Robin Raymond Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 11:00:10 -0000 An interesting read. It makes me wonder if there is a full description available of the SDP that browsers (Chrome, Firefox) currently support. Looking forward to your proposal (I assume it will be on the W3C list?). Cheers, Silvia. On Wed, Jun 26, 2013 at 2:37 PM, Robin Raymond wrote: > > According to many, real adoption of WebRTC will not happen if we continue to > force everyone to use this SDP Offer/Answer methodology. It is clearly > blocking our way forward and the amount of specification documentation > remaining needed for the browser vendors to produce a compatible SDP based > WebRTC engine in a browser is much more daunting than most are willing to > admit. > > > The draft rationale behind a JavaScript Object API model: > > http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt > > Whereas: > > The WebRTC JavaScript Object API & Shim document will be along shortly. > > > We wanted to get this initial rationale draft informational document out > right away. Everyone that has any interest should review the reasons and > concepts and comment before we get too far along on the details of an actual > API, the initial API will follow in the coming days. > > > Best regards, > > Robin Raymond > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From hadriel.kaplan@oracle.com Sat Jul 6 07:58:44 2013 Return-Path: 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 DAC7B21F9C13 for ; Sat, 6 Jul 2013 07:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 0cejXd9svqWQ for ; Sat, 6 Jul 2013 07:58:39 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 84EC021F9C11 for ; Sat, 6 Jul 2013 07:58:39 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r66EwWmm019337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Jul 2013 14:58:32 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r66EwUOr029480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jul 2013 14:58:31 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r66EwUiq007513; Sat, 6 Jul 2013 14:58:30 GMT Received: from dhcp-adc-twvpn-3-vpnpool-10-154-110-216.vpn.oracle.com (/10.154.110.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 06 Jul 2013 07:58:30 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Sat, 6 Jul 2013 10:58:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1CFA0FAA-6FB1-4FB7-A9EE-14BF7587DD05@oracle.com> References: <51CA6FEE.6030702@hookflash.com> <093EDF0B-AFEA-4979-AC72-23AF2FC5E8C7@oracle.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 14:58:45 -0000 Well in our defense, #9 wasn't our argument - that was the argument the = browser makers themselves raised two years ago on the deciding = conference call for why the browsers should be doing SDP rather than a = real API. In fact if I recall right, I think that was the main deciding = argument for why browsers shouldn't offer a lower-level API. -hadriel On Jul 3, 2013, at 6:20 PM, I=F1aki Baz Castillo wrote: > 2013/7/3 Hadriel Kaplan : >> You might also want to cite some of the reasons noted in this old = draft: >> http://tools.ietf.org/html/draft-kaplan-rtcweb-api-reqs-01 >=20 > Well, section "3. Defining a WebRTC Protocol in the Browser" says: >=20 >=20 > 9) Using the SDP offer/answer model provides a more rigid API > interaction model, enabling Browser vendors to perform less > testing and provide more robust implementations than exposing all > discrete components to a Javascript API would. >=20 > 10) Using a higher-level API model, such as would be done with an > SDP offer/answer model, means the cross-browser vendor-specific > variances would be reduced. Exposing a lower-level API would > inevitably lead to some differences in different browsers due to > differences in their architectures/implementation. >=20 >=20 > Time to reconsider those assertions? ;) >=20 >=20 > -- > I=F1aki Baz Castillo > From roman@telurix.com Sun Jul 7 14:15:03 2013 Return-Path: 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 1280E21F9C4F for ; Sun, 7 Jul 2013 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 WulXFLNCqaTZ for ; Sun, 7 Jul 2013 14:14:58 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 53A1D21F9C40 for ; Sun, 7 Jul 2013 14:14:56 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so3381105wiv.15 for ; Sun, 07 Jul 2013 14:14:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=X+lJgIeRhaac3KHwQTtLVA4zYdXdkQp/1oR/XSTPSWU=; b=ccqDfXrmS8Wd4nkEE8I+5T439BNeBJs5GEJBTeNO9itCvPP2079k0eBtKKUC1RGUUn tBEwYBB3BVJ53rlDDdJ5B/+xrAWBuEHm+ThqQQrzO6g4iClLHDocjTf/Ry+45cKkzVnm auRWGpvYzdiadA+pi8P7Z44393qvrdDw8lWZsYHr8hf+TVoiCdmqvDfTWYOo8mYANc2q gRHj7MV5Frnr6x6D0xTlQ0xQlQoVyCTerakk7jRS5KFavjU2ZGiBZwaKcwq1f0ds9SK2 dylEQzFSOxKgjVGr8raIGP4gMGBlQNTlI88iIvdu+ImcUqLlKb8O03HVVartk4tvHpCW ONYg== X-Received: by 10.194.178.138 with SMTP id cy10mr10616865wjc.61.1373231695025; Sun, 07 Jul 2013 14:14:55 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [2a00:1450:400c:c00::233]) by mx.google.com with ESMTPSA id b20sm20245512wiw.4.2013.07.07.14.14.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jul 2013 14:14:54 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so3208283wgh.30 for ; Sun, 07 Jul 2013 14:14:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.85.6 with SMTP id d6mr27525582wiz.47.1373231693136; Sun, 07 Jul 2013 14:14:53 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Sun, 7 Jul 2013 14:14:53 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> Date: Sun, 7 Jul 2013 17:14:53 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: multipart/alternative; boundary=f46d0442808e438c5404e0f26b2a X-Gm-Message-State: ALoCoQno5cwBTkpVgJsjMqTShCEMSVKMV2NC9CVt2/i40VAskV3kiw+fVh/lqF1nIX5AMcIwlAAh Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 21:15:03 -0000 --f46d0442808e438c5404e0f26b2a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jul 6, 2013 at 2:33 AM, Stefan H=E5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 7/3/13 11:37 PM, Eric Rescorla wrote: > > I'm glad to be wrong here. Is the phrase "you shouldn't have to > > modify the SDP but rather there should be API points to cover most > > of the use cases" the consensus of the working group? > > > > > > I thought it was, but I'm not the chair, so maybe you could ask Harald = or > > Stefan. > > I definitely think this is the consensus of the working group. > > Can you point out when exactly this consensus was reached? This is news to me, but I definitely could have missed something. _____________ Roman Shpount --f46d0442808e438c5404e0f26b2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 6, 2013 at 2:33 AM, Stefan H=E5kansson L= K <stefan.lk.hakansson@ericsson.com> wrote:
On 7/3/13 11:37 PM, Eric Rescorla wrote:
= > =A0 =A0 I'm glad to be wrong here. =A0Is the phrase "you shou= ldn't have to
> =A0 =A0 modify the SDP but rather there should be API points to cover = most
> =A0 =A0 of the use cases" =A0the consensus of the working group?<= br> >
>
> I thought it was, but I'm not the chair, so maybe you could ask Ha= rald or
> Stefan.

I definitely think this is the consensus of the working group.


Can you point out when exactly this co= nsensus was reached? This is news to me, but I definitely could have missed= something.
_____________
Roman Shpount

=A0
--f46d0442808e438c5404e0f26b2a-- From fluffy@iii.ca Sun Jul 7 20:40:45 2013 Return-Path: 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 C422321F91B0 for ; Sun, 7 Jul 2013 20:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 eX1XY0JyTzkl for ; Sun, 7 Jul 2013 20:40:40 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0691321F8FAF for ; Sun, 7 Jul 2013 20:40:40 -0700 (PDT) Received: from sjc-vpn3-1183.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D58C822E1FA; Sun, 7 Jul 2013 23:40:32 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Sun, 7 Jul 2013 20:40:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8B58E2AB-09B7-4816-8BC4-B932030E2ED2@iii.ca> References: To: =?windows-1252?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1508) Cc: rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 03:40:45 -0000 On Jul 3, 2013, at 2:42 PM, I=F1aki Baz Castillo wrote: > So compatibility with SIP is important but compatibility with Jingle = is just impossible. The mapping of SDP to jingle is in the Jingle specs =85 I'm not express = any opinion on this one way or another other but the authors of theses = specs have always claimed Jingle fully mapped to and from SDP. From juberti@google.com Sun Jul 7 21:25:10 2013 Return-Path: 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 9932821F9DF0 for ; Sun, 7 Jul 2013 21:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 jfFoO0wCv8ob for ; Sun, 7 Jul 2013 21:25:10 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 87EE121F9DE9 for ; Sun, 7 Jul 2013 21:25:09 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so3525169wiv.5 for ; Sun, 07 Jul 2013 21:25:08 -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 :content-type; bh=WmRRMabkElzwMLZGr+LlnFBFqkm4g8e1sf/GC+YIETo=; b=hN3G0/p3DYmyI/b2yKldmoIGzU4iCx2685BaJi4K5QnOA7ohf46+ALTOdu5sTThGxG PFXYm65BrRbRKFrjnya2W6yvevfHuxv0w/9YPx6F/VXaJROWTt+NSqPLeN+USveW5Okv Wr1KSTecrcJLlyn8DxII2BGAQEhcCNeEKMfQGPTxQSNe4TQzeGvBoe9V5oJbtRROuO9Q ZT5WPSiKSh6TpwnVelI7CshOUlEvONJolNmmFl6e/VideMqeyuMvSJNd585faVX6IluX O3lHkQoX5dkkNMQOKfr5R8cLXg+UDswT3sOcPfyQPbx9oBqGde8t/a8SVs3G2tt7zAIu +vEQ== 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 :content-type:x-gm-message-state; bh=WmRRMabkElzwMLZGr+LlnFBFqkm4g8e1sf/GC+YIETo=; b=BbpNQc8mqY0mXou95aV/7jqXyYUIjU80JhMWNcdW1u1eBKDbrHV3QJRQwkGEu/ktCA AoFcjY3PCJjzdkqJyhp7HdBJFSDqAYie+S/2MB1np9fBjJzBpMp/ai7/Gl5uWX/hk2dY 4w6cJBHDRcEdgaRJYEVKjHVUYiXjlZYsMpNwlxBELRa6RE5UmbT/Skh4SUQ9nt+48u9Q dzL+oj29emGqQDrMNbb8PN7bSyO1Kvs+0ou3lYzau+JIbNP2WAbWMtyMpfoIoeIG7S2n GOT4d4ZX696fnHJhytN+4cWICGM2JGl6OAYDZ7dTVID0NTWjolFjvEKU6dLI0TG0GqKt GQzA== X-Received: by 10.180.96.227 with SMTP id dv3mr10720492wib.59.1373257508580; Sun, 07 Jul 2013 21:25:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Sun, 7 Jul 2013 21:24:48 -0700 (PDT) In-Reply-To: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Mon, 8 Jul 2013 00:24:48 -0400 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d04427270fc208604e0f86dbc X-Gm-Message-State: ALoCoQnuhraxffebVKYffqqL1ny94NVhFWIsyLGRxNFmACDA4TLfRTG1zxWnjrkFveAMQN4VfoUx1TxDcfwBJaQPEJh6aGfr8q1o3akd4EtxRT53aK/VMfHgtqvlE+17aqyhyPcEVKFRyBT1hPfaqVjkWKAqw6I/Is61eFfhk3F3HGj0aBPBFIg5wjJk2kgdgFoc7tTQZXOF Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 04:25:10 -0000 --f46d04427270fc208604e0f86dbc Content-Type: text/plain; charset=UTF-8 Just uploaded a 00 version of a spec for requesting time-limited TURN credentials for WebRTC apps. Would like to get 10 minutes of agenda time to present this in Berlin. ---------- Forwarded message ---------- From: Date: Mon, Jul 8, 2013 at 12:15 AM Subject: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt To: Justin Uberti A new version of I-D, draft-uberti-rtcweb-turn-rest-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: draft-uberti-rtcweb-turn-rest Revision: 00 Title: A REST API For Access To TURN Services Creation date: 2013-07-08 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-turn-rest-00.txt Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-turn-rest Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00 Abstract: This document describes a proposed standard REST API for obtaining access to TURN services via ephemeral (i.e. time-limited) credentials. These credentials are vended by a web service over HTTP, and then supplied to and checked by a TURN server using the standard TURN protocol. The usage of ephemeral credentials ensures that access to the TURN server can be controlled even if the credentials can be discovered by the user, as is the case in WebRTC where TURN credentials must be specified in Javascript. The IETF Secretariat --f46d04427270fc208604e0f86dbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just uploaded a 00 version of a spec for requesting time-l= imited TURN credentials for WebRTC apps. Would like to get 10 minutes of ag= enda time to present this in Berlin.

---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
Date: Mon, Jul 8, 2013 at 12:15 AM
Subject: New Version Notification for= draft-uberti-rtcweb-turn-rest-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-turn-rest-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-uberti-rtcweb-turn-rest
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A REST API For Access To TURN Ser= vices
Creation date: =C2=A0 2013-07-08
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 7
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-turn-rest-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatrack= er.ietf.org/doc/draft-uberti-rtcweb-turn-rest
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h= tml/draft-uberti-rtcweb-turn-rest-00


Abstract:
=C2=A0 =C2=A0This document describes a proposed standard REST API for obtai= ning
=C2=A0 =C2=A0access to TURN services via ephemeral (i.e. time-limited)
=C2=A0 =C2=A0credentials. =C2=A0These credentials are vended by a web servi= ce over
=C2=A0 =C2=A0HTTP, and then supplied to and checked by a TURN server using = the
=C2=A0 =C2=A0standard TURN protocol. =C2=A0The usage of ephemeral credentia= ls ensures
=C2=A0 =C2=A0that access to the TURN server can be controlled even if the =C2=A0 =C2=A0credentials can be discovered by the user, as is the case in W= ebRTC
=C2=A0 =C2=A0where TURN credentials must be specified in Javascript.




The IETF Secretariat



--f46d04427270fc208604e0f86dbc-- From mperumal@cisco.com Sun Jul 7 22:52:57 2013 Return-Path: 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 1DDDE11E818A for ; Sun, 7 Jul 2013 22:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 s9SjnK3QeQj5 for ; Sun, 7 Jul 2013 22:52:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 781AB11E8188 for ; Sun, 7 Jul 2013 22:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18276; q=dns/txt; s=iport; t=1373262771; x=1374472371; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=0ZIYy7cGpyI0I9++Wj7LtebQYcTd5aYatpLmgkXleFE=; b=GqPmS24e6YuRSoeXlYjZhpgCTUw3KzAyvHE4F0P09solOp4fDMiD1Dmt yJsJkUWpUcKkXVVodkKktrhg4JP0Y4xMgcwI5ohnz74XtMZhHeVE7vHAb dJfvLYKtGJm/vvS+vWspArR9wiMmMGmdQUEiWUKxOpKMYNfLMYnSGGMVh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFAKRS2lGtJV2Z/2dsb2JhbABagkVEMk2DCKtwiTeIMRd2FnSCIwEBAQQjCkoSAgEIDgMDAQEBCwwRAwICAjAUCQgCBAESCAESh3QMp0yQRI4zgQcgFwEGDAyCNjNpA5QAhHyQH4FYgTmBaAkXIA X-IronPort-AV: E=Sophos;i="4.87,1016,1363132800"; d="scan'208,217";a="232029975" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 08 Jul 2013 05:52:50 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r685qoih018266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jul 2013 05:52:50 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 00:52:50 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Justin Uberti , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt Thread-Index: AQHOe5MnptNwIaIknUKCiV7zsZZ7FplaO4gA Date: Mon, 8 Jul 2013 05:52:49 +0000 Message-ID: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.211.93] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE224183578xmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 05:52:57 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE224183578xmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpBIGZldyBxdWljayBjb21tZW50czoNCjEpIFRoZSBwcmltYXJ5IGFkdmFu dGFnZSBvZiB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtIHNlZW1zIG5vdCByZXF1aXJpbmcgYW55IGlu dGVyYWN0aW9uIGJldHdlZW4gdGhlIHdlYiBzZXJ2aWNlIGFuZCB0aGUgVFVSTiBzZXJ2aWNlIGlu IG9yZGVyIGZvciB0aGUgVFVSTiBzZXJ2aWNlIHRvIGdyYW50IFRVUk4gY3JlZGVudGlhbHMgaW4g dGhlIEhUVFAgcmVzcG9uc2UgLS0gdGhpcyBhYnNlbmNlIG9mIGludGVyYWN0aW9uIGlzbid0IGV2 aWRlbnQgb24gYSBmaXJzdCByZWFkLiBBIGRpYWdyYW0gc2hvd2luZyB0aGUgY2xpZW50LCB3ZWIg c2VydmljZSwgVFVSTiBzZXJ2aWNlIGFuZCB0aGUgbWVzc2FnZXMgZXhjaGFuZ2VkIHdvdWxkIGJl IGhlbHBmdWwuDQoNCjIpDQp8SWYgZGVzaXJlZCwgdGhlIFRVUk4gc2VydmVyIGNhbiBvcHRpb25h bGx5IHZlcmlmeSB0aGF0IHRoZSBwYXJzZWQNCnx1c2VyIGlkIHZhbHVlIGNvcnJlc3BvbmRzIHRv IGEgY3VycmVudGx5IHZhbGlkIHVzZXIgb2YgYW4gZXh0ZXJuYWwNCnxzZXJ2aWNlIChlLmcuIGlz IGN1cnJlbnRseSBsb2dnZWQgaW4gdG8gdGhlIHdlYiBhcHAgdGhhdCBpcyBtYWtpbmcNCnx1c2Ug b2YgVFVSTikuICBUaGlzIHJlcXVpcmVzIHByb3ByaWV0YXJ5IGNvbW11bmljYXRpb24gYmV0d2Vl biB0aGUNCnxUVVJOIHNlcnZlciBhbmQgZXh0ZXJuYWwgc2VydmljZSBvbiBlYWNoIEFMTE9DQVRF IHJlcXVlc3QsIHNvIHRoaXMNCnx1c2FnZSBpcyBub3QgcmVjb21tZW5kZWQgZm9yIHR5cGljYWwg YXBwbGljYXRpb25zLiAgSWYgdGhpcyBleHRlcm5hbA0KfHZlcmlmaWNhdGlvbiBmYWlscywgaXQg U0hPVUxEIHJlamVjdCB0aGUgcmVxdWVzdCB3aXRoIGEgNDAxDQp8KFVuYXV0aG9yaXplZCkgZXJy b3IuDQoNCldhcyB0aGUgaW50ZW50aW9uIG9mIHB1dHRpbmcgIm5vdCByZWNvbW1lbmRlZCIgaGF2 aW5nIGEgbm9ybWF0aXZlIHN0YXRlbWVudD8gSWYgbm90LCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8g Y2hhbmdlIGl0IHRvICJubyBuZWVkZWQiLg0KDQozKSBUaGVyZSBpcyBubyB0ZXh0IGRlc2NyaWJp bmcgaG93IHRoZSB0aW1lc3RhbXAgZW5jb2RlZCBpbiB0aGUgVU5TRVJOQU1FIGF0dHJpYnV0ZSBv ZiB0aGUgQUxMT0NBRSByZXF1ZXN0ZWQgY291bGQgYmUgcHJvdGVjdGVkLg0KDQo0KSBkcmFmdC1y ZWRkeS1iZWhhdmUtdHVybi1hdXRoIGRlc2NyaWJlcyB0aGUgaXNzdWVzIHdpdGggVFVSTiBhdXRo ZW50aWNhdGlvbiBhbmQgZHJhZnQtdWJlcnRpLXJ0Y3dlYi10dXJuLXJlc3QgbG9va3MgbGlrZSBv bmUgcG9zc2libGUgc29sdXRpb24uIExvb2tzIGJvdGggY291bGQgcmVmZXJlbmNlIGVhY2ggb3Ro ZXIuDQoNCk11dGh1DQoNCkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBN b25kYXksIEp1bHkgMDgsIDIwMTMgOTo1NSBBTQ0KVG86IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVj dDogW3J0Y3dlYl0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXViZXJ0 aS1ydGN3ZWItdHVybi1yZXN0LTAwLnR4dA0KDQpKdXN0IHVwbG9hZGVkIGEgMDAgdmVyc2lvbiBv ZiBhIHNwZWMgZm9yIHJlcXVlc3RpbmcgdGltZS1saW1pdGVkIFRVUk4gY3JlZGVudGlhbHMgZm9y IFdlYlJUQyBhcHBzLiBXb3VsZCBsaWtlIHRvIGdldCAxMCBtaW51dGVzIG9mIGFnZW5kYSB0aW1l IHRvIHByZXNlbnQgdGhpcyBpbiBCZXJsaW4uDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3Nh Z2UgLS0tLS0tLS0tLQ0KRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCkRhdGU6IE1vbiwgSnVsIDgsIDIwMTMgYXQgMTI6MTUg QU0NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdWJlcnRpLXJ0 Y3dlYi10dXJuLXJlc3QtMDAudHh0DQpUbzogSnVzdGluIFViZXJ0aSA8anVzdGluQHViZXJ0aS5u YW1lPG1haWx0bzpqdXN0aW5AdWJlcnRpLm5hbWU+Pg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LXViZXJ0aS1ydGN3ZWItdHVybi1yZXN0LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBKdXN0aW4gVWJlcnRpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtdWJlcnRpLXJ0Y3dlYi10dXJu LXJlc3QNClJldmlzaW9uOiAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAgQSBSRVNUIEFQSSBG b3IgQWNjZXNzIFRvIFRVUk4gU2VydmljZXMNCkNyZWF0aW9uIGRhdGU6ICAgMjAxMy0wNy0wOA0K R3JvdXA6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczog Nw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVzdC0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVz dA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC11YmVy dGktcnRjd2ViLXR1cm4tcmVzdC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgYSBwcm9wb3NlZCBzdGFuZGFyZCBSRVNUIEFQSSBmb3Igb2J0YWluaW5nDQogICBh Y2Nlc3MgdG8gVFVSTiBzZXJ2aWNlcyB2aWEgZXBoZW1lcmFsIChpLmUuIHRpbWUtbGltaXRlZCkN CiAgIGNyZWRlbnRpYWxzLiAgVGhlc2UgY3JlZGVudGlhbHMgYXJlIHZlbmRlZCBieSBhIHdlYiBz ZXJ2aWNlIG92ZXINCiAgIEhUVFAsIGFuZCB0aGVuIHN1cHBsaWVkIHRvIGFuZCBjaGVja2VkIGJ5 IGEgVFVSTiBzZXJ2ZXIgdXNpbmcgdGhlDQogICBzdGFuZGFyZCBUVVJOIHByb3RvY29sLiAgVGhl IHVzYWdlIG9mIGVwaGVtZXJhbCBjcmVkZW50aWFscyBlbnN1cmVzDQogICB0aGF0IGFjY2VzcyB0 byB0aGUgVFVSTiBzZXJ2ZXIgY2FuIGJlIGNvbnRyb2xsZWQgZXZlbiBpZiB0aGUNCiAgIGNyZWRl bnRpYWxzIGNhbiBiZSBkaXNjb3ZlcmVkIGJ5IHRoZSB1c2VyLCBhcyBpcyB0aGUgY2FzZSBpbiBX ZWJSVEMNCiAgIHdoZXJlIFRVUk4gY3JlZGVudGlhbHMgbXVzdCBiZSBzcGVjaWZpZWQgaW4gSmF2 YXNjcmlwdC4NCg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= --_000_E721D8C6A2E1544DB2DEBC313AF54DE224183578xmbrcdx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5IaSBKdXN0aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5BIGZldyBxdWljayBjb21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+MSkgVGhlIHByaW1hcnkgYWR2 YW50YWdlIG9mIHRoZSBwcm9wb3NlZCBtZWNoYW5pc20gc2VlbXMgbm90IHJlcXVpcmluZyBhbnkg aW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgd2ViIHNlcnZpY2UgYW5kIHRoZSBUVVJOIHNlcnZpY2Ug aW4gb3JkZXIgZm9yIHRoZSBUVVJOIHNlcnZpY2UgdG8gZ3JhbnQNCiBUVVJOIGNyZWRlbnRpYWxz IGluIHRoZSBIVFRQIHJlc3BvbnNlIC0tIHRoaXMgYWJzZW5jZSBvZiBpbnRlcmFjdGlvbiBpc24n dCBldmlkZW50IG9uIGEgZmlyc3QgcmVhZC4gQSBkaWFncmFtIHNob3dpbmcgdGhlIGNsaWVudCwg d2ViIHNlcnZpY2UsIFRVUk4gc2VydmljZSBhbmQgdGhlIG1lc3NhZ2VzIGV4Y2hhbmdlZCB3b3Vs ZCBiZSBoZWxwZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+MikNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij58SWYgZGVzaXJlZCwgdGhlIFRVUk4gc2VydmVyIGNhbiBvcHRpb25hbGx5 IHZlcmlmeSB0aGF0IHRoZSBwYXJzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+fHVzZXIgaWQgdmFsdWUgY29y cmVzcG9uZHMgdG8gYSBjdXJyZW50bHkgdmFsaWQgdXNlciBvZiBhbiBleHRlcm5hbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij58c2VydmljZSAoZS5nLiBpcyBjdXJyZW50bHkgbG9nZ2VkIGluIHRvIHRoZSB3ZWIg YXBwIHRoYXQgaXMgbWFraW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnx1c2Ugb2YgVFVSTikuJm5ic3A7IFRo aXMgcmVxdWlyZXMgcHJvcHJpZXRhcnkgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij58VFVSTiBzZXJ2ZXIgYW5kIGV4dGVybmFsIHNlcnZpY2Ugb24gZWFjaCBBTExPQ0FU RSByZXF1ZXN0LCBzbyB0aGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnx1c2FnZSBpcyBub3QgcmVjb21tZW5k ZWQgZm9yIHR5cGljYWwgYXBwbGljYXRpb25zLiZuYnNwOyBJZiB0aGlzIGV4dGVybmFsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPnx2ZXJpZmljYXRpb24gZmFpbHMsIGl0IFNIT1VMRCByZWplY3QgdGhlIHJlcXVl c3Qgd2l0aCBhIDQwMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij58KFVuYXV0aG9yaXplZCkgZXJyb3IuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5XYXMgdGhlIGludGVudGlvbiBvZiBwdXR0 aW5nICZxdW90O25vdCByZWNvbW1lbmRlZCZxdW90OyBoYXZpbmcgYSBub3JtYXRpdmUgc3RhdGVt ZW50PyBJZiBub3QsIGl0IHdvdWxkIGJlIGJldHRlciB0byBjaGFuZ2UgaXQgdG8gJnF1b3Q7bm8g bmVlZGVkJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+MykgVGhl cmUgaXMgbm8gdGV4dCBkZXNjcmliaW5nIGhvdyB0aGUgdGltZXN0YW1wIGVuY29kZWQgaW4gdGhl IFVOU0VSTkFNRSBhdHRyaWJ1dGUgb2YgdGhlIEFMTE9DQUUgcmVxdWVzdGVkIGNvdWxkIGJlIHBy b3RlY3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjQpIGRyYWZ0LXJl ZGR5LWJlaGF2ZS10dXJuLWF1dGggZGVzY3JpYmVzIHRoZSBpc3N1ZXMgd2l0aCBUVVJOIGF1dGhl bnRpY2F0aW9uIGFuZCBkcmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVzdCBsb29rcyBsaWtlIG9u ZSBwb3NzaWJsZSBzb2x1dGlvbi4gTG9va3MgYm90aCBjb3VsZCByZWZlcmVuY2UNCiBlYWNoIG90 aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+TXV0aHU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMDgsIDIwMTMgOTo1NSBBTTxicj4NCjxiPlRv OjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtydGN3ZWJdIEZ3ZDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVz dC0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SnVzdCB1cGxvYWRlZCBhIDAwIHZlcnNpb24gb2YgYSBzcGVjIGZvciByZXF1ZXN0aW5n IHRpbWUtbGltaXRlZCBUVVJOIGNyZWRlbnRpYWxzIGZvciBXZWJSVEMgYXBwcy4gV291bGQgbGlr ZSB0byBnZXQgMTAgbWludXRlcyBvZiBhZ2VuZGEgdGltZSB0byBwcmVzZW50IHRoaXMgaW4gQmVy bGluLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0t LS0tLTxicj4NCkZyb206ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8YnI+ DQpEYXRlOiBNb24sIEp1bCA4LCAyMDEzIGF0IDEyOjE1IEFNPGJyPg0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVzdC0wMC50 eHQ8YnI+DQpUbzogSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1c3RpbkB1YmVy dGkubmFtZSIgdGFyZ2V0PSJfYmxhbmsiPmp1c3RpbkB1YmVydGkubmFtZTwvYT4mZ3Q7PGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXViZXJ0aS1ydGN3 ZWItdHVybi1yZXN0LTAwLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgSnVzdGluIFViZXJ0aSBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48 YnI+DQo8YnI+DQpGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtdWJl cnRpLXJ0Y3dlYi10dXJuLXJlc3Q8YnI+DQpSZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7MDA8YnI+DQpUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBB IFJFU1QgQVBJIEZvciBBY2Nlc3MgVG8gVFVSTiBTZXJ2aWNlczxicj4NCkNyZWF0aW9uIGRhdGU6 ICZuYnNwOyAyMDEzLTA3LTA4PGJyPg0KR3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiA3PGJy Pg0KVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC11YmVydGktcnRjd2Vi LXR1cm4tcmVzdC0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXViZXJ0aS1ydGN3ZWItdHVybi1yZXN0LTAwLnR4dDwvYT48 YnI+DQpTdGF0dXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXViZXJ0aS1ydGN3ZWItdHVybi1y ZXN0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC11YmVydGktcnRjd2ViLXR1cm4tcmVzdDwvYT48YnI+DQpIdG1saXplZDogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dWJlcnRpLXJ0Y3dlYi10dXJuLXJlc3QtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVzdC0wMDwvYT48YnI+DQo8 YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNj cmliZXMgYSBwcm9wb3NlZCBzdGFuZGFyZCBSRVNUIEFQSSBmb3Igb2J0YWluaW5nPGJyPg0KJm5i c3A7ICZuYnNwO2FjY2VzcyB0byBUVVJOIHNlcnZpY2VzIHZpYSBlcGhlbWVyYWwgKGkuZS4gdGlt ZS1saW1pdGVkKTxicj4NCiZuYnNwOyAmbmJzcDtjcmVkZW50aWFscy4gJm5ic3A7VGhlc2UgY3Jl ZGVudGlhbHMgYXJlIHZlbmRlZCBieSBhIHdlYiBzZXJ2aWNlIG92ZXI8YnI+DQombmJzcDsgJm5i c3A7SFRUUCwgYW5kIHRoZW4gc3VwcGxpZWQgdG8gYW5kIGNoZWNrZWQgYnkgYSBUVVJOIHNlcnZl ciB1c2luZyB0aGU8YnI+DQombmJzcDsgJm5ic3A7c3RhbmRhcmQgVFVSTiBwcm90b2NvbC4gJm5i c3A7VGhlIHVzYWdlIG9mIGVwaGVtZXJhbCBjcmVkZW50aWFscyBlbnN1cmVzPGJyPg0KJm5ic3A7 ICZuYnNwO3RoYXQgYWNjZXNzIHRvIHRoZSBUVVJOIHNlcnZlciBjYW4gYmUgY29udHJvbGxlZCBl dmVuIGlmIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtjcmVkZW50aWFscyBjYW4gYmUgZGlzY292ZXJl ZCBieSB0aGUgdXNlciwgYXMgaXMgdGhlIGNhc2UgaW4gV2ViUlRDPGJyPg0KJm5ic3A7ICZuYnNw O3doZXJlIFRVUk4gY3JlZGVudGlhbHMgbXVzdCBiZSBzcGVjaWZpZWQgaW4gSmF2YXNjcmlwdC48 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E721D8C6A2E1544DB2DEBC313AF54DE224183578xmbrcdx02ciscoc_-- From mperumal@cisco.com Sun Jul 7 23:20:04 2013 Return-Path: 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 71DB421F9DE6 for ; Sun, 7 Jul 2013 23:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 9CS3meIU6SE1 for ; Sun, 7 Jul 2013 23:19:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A730121F8574 for ; Sun, 7 Jul 2013 23:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22486; q=dns/txt; s=iport; t=1373264384; x=1374473984; h=from:to:subject:date:message-id:references:mime-version; bh=4xjaITGhKEqmZuNBhWY6xwCbbKMkfLgHwosZt79RIBU=; b=h4Vz1EfQ9KspniCj4gWAPnS4wrnWaimIOTovtsjYpZTljFUq/g9h8B5f r1VOiEcys8n/OWIzyLdAxMI25vljNg3509IeOrV5CYRgpwhd4hBl1d/4g fVPv1gdxdcABP6Hm2nJuehXsB3DPlSQX+X1tEpJm0IUx+Wn3OkYYYkN4n I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFAPtY2lGtJXG8/2dsb2JhbABZgkVEMk2DCKtwiTeIMRd2FnSCIwEBAQQjCkoSAgEIDgMDAQEBCwwRAwICAjAUCQgCBAESCAESh3QMp0SQRo4zgQcWChcHDAyCNjNpA5QAhHyQH4FYgTmBaAkXIA X-IronPort-AV: E=Sophos;i="4.87,1016,1363132800"; d="scan'208,217";a="231760284" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jul 2013 06:19:44 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r686Jh70003428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jul 2013 06:19:44 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 01:19:43 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Justin Uberti , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt Thread-Index: AQHOe5MnptNwIaIknUKCiV7zsZZ7FplaO4gAgAASdMA= Date: Mon, 8 Jul 2013 06:19:43 +0000 Message-ID: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.211.93] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2241836F7xmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 06:20:04 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2241836F7xmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 fDQpIGRyYWZ0LXJlZGR5LWJlaGF2ZS10dXJuLWF1dGggZGVzY3JpYmVzIHRoZSBpc3N1ZXMgd2l0 aCBUVVJODQp8YXV0aGVudGljYXRpb24gYW5kIGRyYWZ0LXViZXJ0aS1ydGN3ZWItdHVybi1yZXN0 IGxvb2tzIGxpa2Ugb25lDQp8cG9zc2libGUgc29sdXRpb24uIExvb2tzIGJvdGggY291bGQgcmVm ZXJlbmNlIGVhY2ggb3RoZXIuDQoNCk1pc3NlZCB0byBtZW50aW9uOg0KQW5kIGl0IHdvdWxkIGJl IGludGVyZXN0aW5nIHRvIHNlZSB3aGF0IGlzc3VlcyBkZXNjcmliZWQgaW4gdGhlIGZvcm1lciBk cmFmdCBhcmUgYWRkcmVzc2VkIGJ5IHRoZSBsYXRlci4uDQoNCk11dGh1DQoNCkZyb206IE11dGh1 IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpDQpTZW50OiBNb25kYXksIEp1bHkgMDgsIDIw MTMgMTE6MjMgQU0NClRvOiAnSnVzdGluIFViZXJ0aSc7IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVj dDogUkU6IFtydGN3ZWJdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC11 YmVydGktcnRjd2ViLXR1cm4tcmVzdC0wMC50eHQNCg0KSGkgSnVzdGluLA0KDQpBIGZldyBxdWlj ayBjb21tZW50czoNCjEpIFRoZSBwcmltYXJ5IGFkdmFudGFnZSBvZiB0aGUgcHJvcG9zZWQgbWVj aGFuaXNtIHNlZW1zIG5vdCByZXF1aXJpbmcgYW55IGludGVyYWN0aW9uIGJldHdlZW4gdGhlIHdl YiBzZXJ2aWNlIGFuZCB0aGUgVFVSTiBzZXJ2aWNlIGluIG9yZGVyIGZvciB0aGUgVFVSTiBzZXJ2 aWNlIHRvIGdyYW50IFRVUk4gY3JlZGVudGlhbHMgaW4gdGhlIEhUVFAgcmVzcG9uc2UgLS0gdGhp cyBhYnNlbmNlIG9mIGludGVyYWN0aW9uIGlzbid0IGV2aWRlbnQgb24gYSBmaXJzdCByZWFkLiBB IGRpYWdyYW0gc2hvd2luZyB0aGUgY2xpZW50LCB3ZWIgc2VydmljZSwgVFVSTiBzZXJ2aWNlIGFu ZCB0aGUgbWVzc2FnZXMgZXhjaGFuZ2VkIHdvdWxkIGJlIGhlbHBmdWwuDQoNCjIpDQp8SWYgZGVz aXJlZCwgdGhlIFRVUk4gc2VydmVyIGNhbiBvcHRpb25hbGx5IHZlcmlmeSB0aGF0IHRoZSBwYXJz ZWQNCnx1c2VyIGlkIHZhbHVlIGNvcnJlc3BvbmRzIHRvIGEgY3VycmVudGx5IHZhbGlkIHVzZXIg b2YgYW4gZXh0ZXJuYWwNCnxzZXJ2aWNlIChlLmcuIGlzIGN1cnJlbnRseSBsb2dnZWQgaW4gdG8g dGhlIHdlYiBhcHAgdGhhdCBpcyBtYWtpbmcNCnx1c2Ugb2YgVFVSTikuICBUaGlzIHJlcXVpcmVz IHByb3ByaWV0YXJ5IGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUNCnxUVVJOIHNlcnZlciBhbmQg ZXh0ZXJuYWwgc2VydmljZSBvbiBlYWNoIEFMTE9DQVRFIHJlcXVlc3QsIHNvIHRoaXMNCnx1c2Fn ZSBpcyBub3QgcmVjb21tZW5kZWQgZm9yIHR5cGljYWwgYXBwbGljYXRpb25zLiAgSWYgdGhpcyBl eHRlcm5hbA0KfHZlcmlmaWNhdGlvbiBmYWlscywgaXQgU0hPVUxEIHJlamVjdCB0aGUgcmVxdWVz dCB3aXRoIGEgNDAxDQp8KFVuYXV0aG9yaXplZCkgZXJyb3IuDQoNCldhcyB0aGUgaW50ZW50aW9u IG9mIHB1dHRpbmcgIm5vdCByZWNvbW1lbmRlZCIgaGF2aW5nIGEgbm9ybWF0aXZlIHN0YXRlbWVu dD8gSWYgbm90LCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2hhbmdlIGl0IHRvICJubyBuZWVkZWQi Lg0KDQozKSBUaGVyZSBpcyBubyB0ZXh0IGRlc2NyaWJpbmcgaG93IHRoZSB0aW1lc3RhbXAgZW5j b2RlZCBpbiB0aGUgVU5TRVJOQU1FIGF0dHJpYnV0ZSBvZiB0aGUgQUxMT0NBRSByZXF1ZXN0ZWQg Y291bGQgYmUgcHJvdGVjdGVkLg0KDQo0KSBkcmFmdC1yZWRkeS1iZWhhdmUtdHVybi1hdXRoIGRl c2NyaWJlcyB0aGUgaXNzdWVzIHdpdGggVFVSTiBhdXRoZW50aWNhdGlvbiBhbmQgZHJhZnQtdWJl cnRpLXJ0Y3dlYi10dXJuLXJlc3QgbG9va3MgbGlrZSBvbmUgcG9zc2libGUgc29sdXRpb24uIExv b2tzIGJvdGggY291bGQgcmVmZXJlbmNlIGVhY2ggb3RoZXIuDQoNCk11dGh1DQoNCkZyb206IHJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz4gW21h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkN ClNlbnQ6IE1vbmRheSwgSnVseSAwOCwgMjAxMyA5OjU1IEFNDQpUbzogcnRjd2ViQGlldGYub3Jn PG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbcnRjd2ViXSBGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdWJlcnRpLXJ0Y3dlYi10dXJuLXJlc3QtMDAudHh0 DQoNCkp1c3QgdXBsb2FkZWQgYSAwMCB2ZXJzaW9uIG9mIGEgc3BlYyBmb3IgcmVxdWVzdGluZyB0 aW1lLWxpbWl0ZWQgVFVSTiBjcmVkZW50aWFscyBmb3IgV2ViUlRDIGFwcHMuIFdvdWxkIGxpa2Ug dG8gZ2V0IDEwIG1pbnV0ZXMgb2YgYWdlbmRhIHRpbWUgdG8gcHJlc2VudCB0aGlzIGluIEJlcmxp bi4NCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0K RGF0ZTogTW9uLCBKdWwgOCwgMjAxMyBhdCAxMjoxNSBBTQ0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVzdC0wMC50eHQNClRv OiBKdXN0aW4gVWJlcnRpIDxqdXN0aW5AdWJlcnRpLm5hbWU8bWFpbHRvOmp1c3RpbkB1YmVydGku bmFtZT4+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdWJlcnRpLXJ0Y3dlYi10 dXJuLXJlc3QtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEp1c3Rp biBVYmVydGkgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 ICAgICAgICBkcmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVzdA0KUmV2aXNpb246ICAgICAgICAw MA0KVGl0bGU6ICAgICAgICAgICBBIFJFU1QgQVBJIEZvciBBY2Nlc3MgVG8gVFVSTiBTZXJ2aWNl cw0KQ3JlYXRpb24gZGF0ZTogICAyMDEzLTA3LTA4DQpHcm91cDogICAgICAgICAgIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3DQpVUkw6ICAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXViZXJ0aS1ydGN3ZWItdHVybi1y ZXN0LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXViZXJ0aS1ydGN3ZWItdHVybi1yZXN0DQpIdG1saXplZDogICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXViZXJ0aS1ydGN3ZWItdHVybi1yZXN0LTAwDQoN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHByb3Bvc2VkIHN0YW5k YXJkIFJFU1QgQVBJIGZvciBvYnRhaW5pbmcNCiAgIGFjY2VzcyB0byBUVVJOIHNlcnZpY2VzIHZp YSBlcGhlbWVyYWwgKGkuZS4gdGltZS1saW1pdGVkKQ0KICAgY3JlZGVudGlhbHMuICBUaGVzZSBj cmVkZW50aWFscyBhcmUgdmVuZGVkIGJ5IGEgd2ViIHNlcnZpY2Ugb3Zlcg0KICAgSFRUUCwgYW5k IHRoZW4gc3VwcGxpZWQgdG8gYW5kIGNoZWNrZWQgYnkgYSBUVVJOIHNlcnZlciB1c2luZyB0aGUN CiAgIHN0YW5kYXJkIFRVUk4gcHJvdG9jb2wuICBUaGUgdXNhZ2Ugb2YgZXBoZW1lcmFsIGNyZWRl bnRpYWxzIGVuc3VyZXMNCiAgIHRoYXQgYWNjZXNzIHRvIHRoZSBUVVJOIHNlcnZlciBjYW4gYmUg Y29udHJvbGxlZCBldmVuIGlmIHRoZQ0KICAgY3JlZGVudGlhbHMgY2FuIGJlIGRpc2NvdmVyZWQg YnkgdGhlIHVzZXIsIGFzIGlzIHRoZSBjYXNlIGluIFdlYlJUQw0KICAgd2hlcmUgVFVSTiBjcmVk ZW50aWFscyBtdXN0IGJlIHNwZWNpZmllZCBpbiBKYXZhc2NyaXB0Lg0KDQoNCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_E721D8C6A2E1544DB2DEBC313AF54DE2241836F7xmbrcdx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciLCJzZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciLCJzZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPnw0KSBkcmFmdC1yZWRkeS1iZWhhdmUtdHVybi1hdXRoIGRl c2NyaWJlcyB0aGUgaXNzdWVzIHdpdGggVFVSTg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnxhdXRoZW50aWNh dGlvbiBhbmQgZHJhZnQtdWJlcnRpLXJ0Y3dlYi10dXJuLXJlc3QgbG9va3MgbGlrZSBvbmUNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij58cG9zc2libGUgc29sdXRpb24uIExvb2tzIGJvdGggY291bGQgcmVmZXJl bmNlIGVhY2ggb3RoZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5NaXNz ZWQgdG8gbWVudGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QW5kIGl0IHdvdWxkIGJlIGludGVyZXN0aW5n IHRvIHNlZSB3aGF0IGlzc3VlcyBkZXNjcmliZWQgaW4gdGhlIGZvcm1lciBkcmFmdCBhcmUgYWRk cmVzc2VkIGJ5IHRoZSBsYXRlci4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5NdXRodTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNdXRodSBBcnVsIE1vemhpIFBl cnVtYWwgKG1wZXJ1bWFsKQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAwOCwgMjAx MyAxMToyMyBBTTxicj4NCjxiPlRvOjwvYj4gJ0p1c3RpbiBVYmVydGknOyBydGN3ZWJAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtydGN3ZWJdIEZ3ZDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVzdC0wMC50eHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+SGkgSnVzdGluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+QSBmZXcgcXVpY2sgY29tbWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjEpIFRoZSBwcmltYXJ5IGFk dmFudGFnZSBvZiB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtIHNlZW1zIG5vdCByZXF1aXJpbmcgYW55 IGludGVyYWN0aW9uIGJldHdlZW4gdGhlIHdlYiBzZXJ2aWNlIGFuZCB0aGUgVFVSTiBzZXJ2aWNl IGluIG9yZGVyIGZvciB0aGUgVFVSTiBzZXJ2aWNlIHRvIGdyYW50DQogVFVSTiBjcmVkZW50aWFs cyBpbiB0aGUgSFRUUCByZXNwb25zZSAtLSB0aGlzIGFic2VuY2Ugb2YgaW50ZXJhY3Rpb24gaXNu J3QgZXZpZGVudCBvbiBhIGZpcnN0IHJlYWQuIEEgZGlhZ3JhbSBzaG93aW5nIHRoZSBjbGllbnQs IHdlYiBzZXJ2aWNlLCBUVVJOIHNlcnZpY2UgYW5kIHRoZSBtZXNzYWdlcyBleGNoYW5nZWQgd291 bGQgYmUgaGVscGZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjIpDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+fElmIGRlc2lyZWQsIHRoZSBUVVJOIHNlcnZlciBjYW4gb3B0aW9uYWxs eSB2ZXJpZnkgdGhhdCB0aGUgcGFyc2VkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnx1c2VyIGlkIHZhbHVlIGNv cnJlc3BvbmRzIHRvIGEgY3VycmVudGx5IHZhbGlkIHVzZXIgb2YgYW4gZXh0ZXJuYWw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+fHNlcnZpY2UgKGUuZy4gaXMgY3VycmVudGx5IGxvZ2dlZCBpbiB0byB0aGUgd2Vi IGFwcCB0aGF0IGlzIG1ha2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij58dXNlIG9mIFRVUk4pLiZuYnNwOyBU aGlzIHJlcXVpcmVzIHByb3ByaWV0YXJ5IGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+fFRVUk4gc2VydmVyIGFuZCBleHRlcm5hbCBzZXJ2aWNlIG9uIGVhY2ggQUxMT0NB VEUgcmVxdWVzdCwgc28gdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij58dXNhZ2UgaXMgbm90IHJlY29tbWVu ZGVkIGZvciB0eXBpY2FsIGFwcGxpY2F0aW9ucy4mbmJzcDsgSWYgdGhpcyBleHRlcm5hbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij58dmVyaWZpY2F0aW9uIGZhaWxzLCBpdCBTSE9VTEQgcmVqZWN0IHRoZSByZXF1 ZXN0IHdpdGggYSA0MDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+fChVbmF1dGhvcml6ZWQpIGVycm9yLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+V2FzIHRoZSBpbnRlbnRpb24gb2YgcHV0 dGluZyAmcXVvdDtub3QgcmVjb21tZW5kZWQmcXVvdDsgaGF2aW5nIGEgbm9ybWF0aXZlIHN0YXRl bWVudD8gSWYgbm90LCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2hhbmdlIGl0IHRvICZxdW90O25v IG5lZWRlZCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjMpIFRo ZXJlIGlzIG5vIHRleHQgZGVzY3JpYmluZyBob3cgdGhlIHRpbWVzdGFtcCBlbmNvZGVkIGluIHRo ZSBVTlNFUk5BTUUgYXR0cmlidXRlIG9mIHRoZSBBTExPQ0FFIHJlcXVlc3RlZCBjb3VsZCBiZSBw cm90ZWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij40KSBkcmFmdC1y ZWRkeS1iZWhhdmUtdHVybi1hdXRoIGRlc2NyaWJlcyB0aGUgaXNzdWVzIHdpdGggVFVSTiBhdXRo ZW50aWNhdGlvbiBhbmQgZHJhZnQtdWJlcnRpLXJ0Y3dlYi10dXJuLXJlc3QgbG9va3MgbGlrZSBv bmUgcG9zc2libGUgc29sdXRpb24uIExvb2tzIGJvdGggY291bGQgcmVmZXJlbmNlDQogZWFjaCBv dGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk11dGh1PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmciPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dl Yi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgSnVseSAwOCwgMjAxMyA5OjU1IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtydGN3ZWJdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC11YmVydGkt cnRjd2ViLXR1cm4tcmVzdC0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCB1cGxvYWRlZCBhIDAwIHZlcnNpb24gb2YgYSBzcGVj IGZvciByZXF1ZXN0aW5nIHRpbWUtbGltaXRlZCBUVVJOIGNyZWRlbnRpYWxzIGZvciBXZWJSVEMg YXBwcy4gV291bGQgbGlrZSB0byBnZXQgMTAgbWludXRlcyBvZiBhZ2VuZGEgdGltZSB0byBwcmVz ZW50IHRoaXMgaW4gQmVybGluLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPi0tLS0tLS0tLS0gRm9yd2FyZGVk IG1lc3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZyb206ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPC9hPiZndDs8YnI+DQpEYXRlOiBNb24sIEp1bCA4LCAyMDEzIGF0IDEyOjE1IEFNPGJyPg0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC11YmVydGktcnRjd2Vi LXR1cm4tcmVzdC0wMC50eHQ8YnI+DQpUbzogSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmp1c3RpbkB1YmVydGkubmFtZSIgdGFyZ2V0PSJfYmxhbmsiPmp1c3RpbkB1YmVydGkubmFt ZTwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXViZXJ0aS1ydGN3ZWItdHVybi1yZXN0LTAwLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSnVzdGluIFViZXJ0aSBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklF VEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ZHJhZnQtdWJlcnRpLXJ0Y3dlYi10dXJuLXJlc3Q8YnI+DQpSZXZpc2lvbjogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBBIFJFU1QgQVBJIEZvciBBY2Nlc3MgVG8gVFVSTiBTZXJ2aWNlczxicj4N CkNyZWF0aW9uIGRhdGU6ICZuYnNwOyAyMDEzLTA3LTA4PGJyPg0KR3JvdXA6ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KTnVtYmVy IG9mIHBhZ2VzOiA3PGJyPg0KVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC11YmVydGktcnRjd2ViLXR1cm4tcmVzdC0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXViZXJ0aS1ydGN3ZWItdHVybi1y ZXN0LTAwLnR4dDwvYT48YnI+DQpTdGF0dXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXViZXJ0 aS1ydGN3ZWItdHVybi1yZXN0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVzdDwvYT48YnI+DQpIdG1saXpl ZDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtdWJlcnRpLXJ0Y3dlYi10dXJuLXJlc3QtMDAiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC11YmVydGktcnRjd2ViLXR1cm4tcmVz dC0wMDwvYT48YnI+DQo8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7VGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYSBwcm9wb3NlZCBzdGFuZGFyZCBSRVNUIEFQSSBmb3Igb2J0 YWluaW5nPGJyPg0KJm5ic3A7ICZuYnNwO2FjY2VzcyB0byBUVVJOIHNlcnZpY2VzIHZpYSBlcGhl bWVyYWwgKGkuZS4gdGltZS1saW1pdGVkKTxicj4NCiZuYnNwOyAmbmJzcDtjcmVkZW50aWFscy4g Jm5ic3A7VGhlc2UgY3JlZGVudGlhbHMgYXJlIHZlbmRlZCBieSBhIHdlYiBzZXJ2aWNlIG92ZXI8 YnI+DQombmJzcDsgJm5ic3A7SFRUUCwgYW5kIHRoZW4gc3VwcGxpZWQgdG8gYW5kIGNoZWNrZWQg YnkgYSBUVVJOIHNlcnZlciB1c2luZyB0aGU8YnI+DQombmJzcDsgJm5ic3A7c3RhbmRhcmQgVFVS TiBwcm90b2NvbC4gJm5ic3A7VGhlIHVzYWdlIG9mIGVwaGVtZXJhbCBjcmVkZW50aWFscyBlbnN1 cmVzPGJyPg0KJm5ic3A7ICZuYnNwO3RoYXQgYWNjZXNzIHRvIHRoZSBUVVJOIHNlcnZlciBjYW4g YmUgY29udHJvbGxlZCBldmVuIGlmIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtjcmVkZW50aWFscyBj YW4gYmUgZGlzY292ZXJlZCBieSB0aGUgdXNlciwgYXMgaXMgdGhlIGNhc2UgaW4gV2ViUlRDPGJy Pg0KJm5ic3A7ICZuYnNwO3doZXJlIFRVUk4gY3JlZGVudGlhbHMgbXVzdCBiZSBzcGVjaWZpZWQg aW4gSmF2YXNjcmlwdC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNy ZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_E721D8C6A2E1544DB2DEBC313AF54DE2241836F7xmbrcdx02ciscoc_-- From ibc@aliax.net Mon Jul 8 03:39:08 2013 Return-Path: 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 B445511E819F for ; Mon, 8 Jul 2013 03:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 2xpKNWa733lp for ; Mon, 8 Jul 2013 03:39:03 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8C59B21F9ECE for ; Mon, 8 Jul 2013 03:39:03 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so2142461qcx.21 for ; Mon, 08 Jul 2013 03:39:01 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=48xLsXrBRPQ6eOQxsKfqLlAycT83Puv1hT1D0dFYL0w=; b=TtFOzpnKVi/tifscyceAzlwI+LZ3347ysnbVfIpfCJo1B0hHrq1nvE2N/xb951h7IA DnAjcasvWY49rAOZuZKIhLbBID51RjeouY1FLggeeTPz4P91kSdou2lfHlPmt7MiU4Ej W272pfGPBJGpgAfO81N5qYpRtub/+8KDiKMufuzrOmKDequzby+HVb+wb2VHRHily/XO DyFXubVFHEjtCnjN4DaBtxAhkdxzRNGflQHcPWboZK5F/2lGNYywm5doPEA3yD+ywuEx vsjrpQYrJO4uIYe3/dScQa1HXTo713CP9He2tfOx5+S7SmnwYWMbnfoJGICPspKgZ7Bi p8oA== X-Received: by 10.224.22.67 with SMTP id m3mr18098804qab.36.1373279941550; Mon, 08 Jul 2013 03:39:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 8 Jul 2013 03:38:41 -0700 (PDT) In-Reply-To: <8B58E2AB-09B7-4816-8BC4-B932030E2ED2@iii.ca> References: <8B58E2AB-09B7-4816-8BC4-B932030E2ED2@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Jul 2013 12:38:41 +0200 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlNC5GHxrZJIea2zQg6atIK2FhVnT5kvPmWOhDKpHniWY1ajOPeV3YB1+7RV5//4xHhzzDX Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 10:39:08 -0000 2013/7/8 Cullen Jennings : >> So compatibility with SIP is important but compatibility with Jingle is = just impossible. > > The mapping of SDP to jingle is in the Jingle specs =E2=80=A6 I'm not exp= ress any opinion on this one way or another other but the authors of theses= specs have always claimed Jingle fully mapped to and from SDP. XEP-0167 defines a XML based SDP. Mapping it from/to plain SDP requires, at least, having all the attributes of the SDP. Instead you are proposing that the JS receives an opaque SDP blob from the browser, so it must be parsed via JS if the app wants to convert it into XML SDP. It's really ugly and the worst specification for the Web. -- I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Mon Jul 8 05:12:06 2013 Return-Path: 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 3BEB611E81B6 for ; Mon, 8 Jul 2013 05:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.176 X-Spam-Level: X-Spam-Status: No, score=-5.176 tagged_above=-999 required=5 tests=[AWL=0.773, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 g-zB1OydFxH1 for ; Mon, 8 Jul 2013 05:12:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8258D21F9EB2 for ; Mon, 8 Jul 2013 05:11:59 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-68-51daac8d7394 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 67.28.05990.D8CAAD15; Mon, 8 Jul 2013 14:11:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Mon, 8 Jul 2013 14:11:57 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Roman Shpount Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOeDFbTNRhHYI3NkSZeqhrbqmeQg== Date: Mon, 8 Jul 2013 12:11:56 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvrW7vmluBBi82qFuseH2O3WLGhanM Fmv/tbM7MHssWfKTyWPy4zZmj1tTCgKYo7hsUlJzMstSi/TtErgyThy5yVzQxldxrfEuYwPj Z64uRk4OCQETic5Vr5khbDGJC/fWs3UxcnEICRxmlDh58BI7SEJIYCGjRMeRCBCbTSBQYuu+ BWwgtoiAqsTf75OZQGxmAXeJXTdug9nCAlUSyw8fA+rlAKqplljSXw5RrifRdXErC4jNIqAi 8f//FrASXgFfica3phBrNzBLvLtyCayGEeie76fWQI0Xl7j1ZD4TxJ0CEkv2nIe6WVTi5eN/ rBC2kkTjkiesEPV6EjemTmGDsLUlli2E+JFXQFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZ xciem5iZk15utIkRGBsHt/xW3cF455zIIUZpDhYlcd7NemcChQTSE0tSs1NTC1KL4otKc1KL DzEycXBKNTB6X1eLSnPnXaRyjVVx8+7JEbc4ciZfaMj4u3jV3b6ZpS9lzts1NV89Yd/J813d 0YozPVz286fI6Uozd7D6TKiQ+z3pd8oR9kVL8m8WHwpc0dt5+MkJD9EvLNMkJjrd4OD6uD/y 1L2ujW1uablXr1+pO3Svqua4RJ6qaKlBlP0v/frvr966fzNWYinOSDTUYi4qTgQA+gjW9lsC AAA= Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:12:06 -0000 On 7/7/13 11:14 PM, Roman Shpount wrote:=0A= >=0A= > On Sat, Jul 6, 2013 at 2:33 AM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > On 7/3/13 11:37 PM, Eric Rescorla wrote:=0A= > > I'm glad to be wrong here. Is the phrase "you shouldn't have = to=0A= > > modify the SDP but rather there should be API points to cover= =0A= > most=0A= > > of the use cases" the consensus of the working group?=0A= > >=0A= > >=0A= > > I thought it was, but I'm not the chair, so maybe you could ask=0A= > Harald or=0A= > > Stefan.=0A= >=0A= > I definitely think this is the consensus of the working group.=0A= >=0A= >=0A= > Can you point out when exactly this consensus was reached? This is news= =0A= > to me, but I definitely could have missed something.=0A= =0A= No I can't really. To be clear, no consensus call (or similar) has been =0A= held. But every time this is discussed, what I hear is people agreeing =0A= and no objections. It was discussed a bit, e.g., at the f2f at TPAC last = =0A= year, if you read the minutes [1] you will find some traces of that =0A= discussion.=0A= =0A= And, I don't understand why there would be a debate about this. There =0A= are obviously many who want to define APIs (or constraints) that allow =0A= most use-cases to be met without having to modify the SDP. Why would =0A= anyone have anything against that? If there is anyone who really wants =0A= to modify the SDP instead (I have no clue why, but anyway) they can =0A= still do that.=0A= =0A= [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Nov/0072.html=0A= =0A= > _____________=0A= > Roman Shpount=0A= >=0A= =0A= From simon.perreault@viagenie.ca Mon Jul 8 05:23:41 2013 Return-Path: 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 247EA11E81D4 for ; Mon, 8 Jul 2013 05:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, 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 FMw7hz95MdGi for ; Mon, 8 Jul 2013 05:23:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E511E81CE for ; Mon, 8 Jul 2013 05:23:40 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:c15b:51e7:d305:cc6c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 62DBE47142 for ; Mon, 8 Jul 2013 08:23:39 -0400 (EDT) Message-ID: <51DAAF4B.4070004@viagenie.ca> Date: Mon, 08 Jul 2013 14:23:39 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:23:41 -0000 Le 2013-07-08 06:24, Justin Uberti a écrit : > Just uploaded a 00 version of a spec for requesting time-limited TURN > credentials for WebRTC apps. Would like to get 10 minutes of agenda time > to present this in Berlin. Cool. One small comment: shouldn't the response also contain the value of the REALM parameter? Thanks, Simon From pthatcher@google.com Mon Jul 8 06:57:34 2013 Return-Path: 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 A482121F9C87 for ; Mon, 8 Jul 2013 06:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 H5Z6zLLQjRrD for ; Mon, 8 Jul 2013 06:57:33 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C38FC21F9C81 for ; Mon, 8 Jul 2013 06:57:28 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id tj12so4424656pac.12 for ; Mon, 08 Jul 2013 06:57:28 -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 :content-type; bh=5ViZzIlguF64Vvj8aJAVH04eAFRwX1WylWaMfu8FM6E=; b=VEhp6BJJJdrb1kuNCAZdr2Jwqqoyyy7062t4xc7my19yRcyhwirvejvLegwzZUpj4+ whAkKLYLv+/SfX31gv+fDsKdrMSaeA+icA4wg65SmmGtOwawEhOHcSuvrQCdZleVspWQ NmxKQrou6cTGnuvORgWldx/BQCEQDiZrEVf5iwT9/te09CiexFHfqUsTlDjftp4XZozM DmIzj7AjcJeCBSrnfaVUlBk0v8tOaPtHnhuKB1YAgDvf2KeS8sru0cHARRuNtN7tKH22 q3aSCkbXqJuP6v1xlIAFLrPilZMarJwy5UxnM7Y5wqjHVsn/qowe6E3oc43XRCQcFB91 adNQ== 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 :content-type:x-gm-message-state; bh=5ViZzIlguF64Vvj8aJAVH04eAFRwX1WylWaMfu8FM6E=; b=IpyN/yZHUfPu0BvMaGUCSyFBLPMdDtmhW5w4WrGNAG2YjwweTzDzw6APPnFlOt2KNE cDjwnncCWwxLMqb0G1IVtFrUwu+dhCXMIlNt0kWZhvFb1N+s2FNerwuLQDY7yErtGZ+B genZDPf3dP4Xpacx8ejiOGR3E15iLx+8uwI0dk8ovKk4QsWCJLIuO7dlk7O1M4vu/zvh ghN7esxNwuNIRpEM5JD0ZO/RWI9gzalZmllVcrvION4ohDB2i6gSzqC3S7RX/zy6CUVq X7qEE9PSo6fxkvQnolxju470m9FHCGgQbUU/E0vlowfGR17gtsMSoeb5jCsfbZW4r4sb 3wbg== X-Received: by 10.66.141.4 with SMTP id rk4mr22823409pab.127.1373291848492; Mon, 08 Jul 2013 06:57:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 06:56:48 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Mon, 8 Jul 2013 06:56:48 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a11c39d18cd80e304e1006c57 X-Gm-Message-State: ALoCoQladXxw2IOTtDdUTb4i0dJPDY7gLafIV3tTWugVgVDKS51+e3cks5yCMX0DIAyZmsq/DyrpvnIFmJfBavL6ya3Q3pn8Lz4agKOEXIQpA8gUR4g+RrFa8Q9wHFF6G6vxdgrIJVZVJNpD/e5BfRWILJU8NPLto4AL7j2FXj+W9xn/Uq3XEap3Fnfc7C7+vspCABeGWaBN 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 13:57:34 -0000 --001a11c39d18cd80e304e1006c57 Content-Type: text/plain; charset=UTF-8 Just in case it is missed elsewhere in the thread, I'll reply directly to my own message. It was pointed out to me that I made a mistake with my addition. The first line should have read: 61% "Good for simple Stuff" 39% "Bad for simple stuff" Sorry about that. On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher wrote: > After about a week of input, and feedback from 19 developers doing a wide > range of things using the WebRTC API, we have some data about their opinion > of the current API. > > *Short answer*: > > 61% "Good for simple Stuff" 49% "Bad for simple stuff" > 6% "Good for advanced stuff" 94% "Bad for advanced stuff" > 46% "Good/OK/tolerable for 1.0" 54% "Horrible/intolerable for 1.0" > 7% "Good/OK/tolerable long-term" 93% "Need a better API long-term" > > > In general the attitude is *"It's OK for simple stuff but bad for > advanced stuff", *and *"We can tolerate it for 1.0, but we need > something better for 2.0". *But the majority of the feedback was against > it even for the 1.0, so the last one is a bit of a stretch. > > > *Long Answer*: > > I had to interpret the results a little to fit into these buckets, so if > you don't like the interpretation, you're more than welcome to interpret > your own results from the raw data: > https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=1 > > > There seem to be 4 or 5 different camps: > > Camp #1: Doing very simple things, doesn't touch the SDP. Everything is > fine, except they might have things they want to control but can't. > > Camp #2: Does somewhat more advanced things, touches the SDP a little, > has pain, anticipates more pain, would like something better, but thinks > this is OK for 1.0. > > Camp #3: Is trying advanced things, is touching the SDP a lot, and really > feels pain. Wants something better, and might tolerate this API for 1.0, > but not for long. > > Camp #4: Doesn't want SDP or O/A in the API at all. Has a very strong > dislike for it. Won't tolerate it, even for 1.0. The IETF and W3C should > be embarrassed for even suggesting such a terrible API. It's better to go > back to the drawing board (if you think those words are strong, go read the > spreadsheet or mailing list!) > > Oh, and of course, for completeness, we should describe Camp #0, which > didn't have any input in this feedback: > > Camp #0: I've used SDP for years and I'm very comfortable with it. Using > SDP as the control surface really helps my use case, which is legacy > interop. Defining an API without SDP would be too much work, and probably > fail. Look at what happened with SDPng! Supporting all these advanced use > cases doesn't seem worth it. If developers are doing that much advanced > stuff, they can learn to munge SDP. It isn't that bad. > > (By the way, I'm not a member of Camp #0, so I may be a little off in my > description of it. If any member of Camp #0 would like to adjust that > description, please feel free). > > > > > *Suggested Next Step: Figure out what is needed for WebRTC++* > * > * > As Cullen recently pointed out, we need to get a list of things developers > want to be able to control in a future version of the API which could > hopefully make developers happier Whether that future API is 1.0, 2.0, or > 1.1 is an orthogonal question, but let's call it WebRTC++ for now. > Clearly, they want a way to control things without SDP, and perhaps without > O/A at all. But what do they want to control? We need a good list. > > I suggest we reach out more closely to the developers, and use their input > to create not only a list of things they want to do, but a WebRTC++ API > that fulfills those needs without requiring SDP munging. I think we can do > this in parallel with the current API work without detracting from it > (from the current work, that is). Certainly there is plenty of energy > from people interested in working on it (WebRTC++, that is). Such parallel > work would not only better capture the needs of developers, but could also > improve the WebRTC (not ++) API by incorporating ideas from it. > > So far, such activity has been frowned on, perhaps out of fear that it's a > threat to the current work. But I think it can be done in a way that > doesn't threaten anything, and even learns from and builds on the valuable > input we are receiving from developers. The alternative is to ask all > these developers to wait an indefinite amount of time and munge SDP like > crazy until then, and that seems like a rather poor answer. Therefore, I > would support an exploratory effort at a "WebRTC++ API". > > > > > > > > --001a11c39d18cd80e304e1006c57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just in case it is missed elsewhere in the thread, I'l= l reply directly to my own message. =C2=A0It was pointed out to me that I m= ade a mistake with my addition. =C2=A0The first line should have read:
=
61% "Good for simple Stuff" =C2=A0 =C2=A0 =C2=A0 =C2=A0= 39% "Bad for simple stuff"

Sor= ry about that. =C2=A0


On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher <pth= atcher@google.com> wrote:
After about a week of input= , and feedback from 19 developers doing a wide range of things using the We= bRTC API, we have some data about their opinion of the current API.

Short answer:

61%=C2=A0"Good = for simple Stuff"=C2=A0 =C2=A0 49% "Bad for simple stuff"
=C2=A06%= =C2=A0"Good for advanced = stuff" =C2=A0 =C2=A0 =C2=A094% "Bad for advanced stuff"
46= %=C2=A0"Good/OK/tolerable= for 1.0" =C2=A0 =C2=A054% "Horrible/intolerable for 1.0"
=C2=A07%= =C2=A0"Good/OK/tolerable = long-term" =C2=A093% "Need a better API long-term"=C2=A0


In general the attitude is &quo= t;It's OK for simple stuff but bad for advanced stuff", =C2=A0= and "We can tolerate it for 1.0, but we need something better for 2= .0". =C2=A0But the majority of the feedback was against it even fo= r the 1.0, so the last one is a bit of a stretch.


Long Answer:

=
I had to interpret the results a little to fit into these buckets= , so if you don't like the interpretation, you're more than welcome= to interpret your own results from the raw data: =C2=A0https://docs.google.com/spreadsheet/ccc?= key=3D0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1


There seem to be 4 or 5 different = camps:

Camp #1: =C2=A0Doing very simple things, do= esn't touch the SDP. =C2=A0Everything is fine, except they might have t= hings they want to control but can't.

Camp #2: =C2=A0Does somewhat more advanced things, touc= hes the SDP a little, has pain, anticipates more pain, would like something= better, but thinks this is OK for 1.0.

Camp #3: = =C2=A0Is trying advanced things, is touching the SDP a lot, and really feel= s pain. =C2=A0Wants something better, and might tolerate this API for 1.0, = but not for long.

Camp #4: =C2=A0Doesn't want SDP or O/A in the API a= t all. =C2=A0Has a very strong dislike for it. =C2=A0Won't tolerate it,= even for 1.0. =C2=A0The IETF and W3C should be embarrassed for even sugges= ting such a terrible API. =C2=A0It's better to go back to the drawing b= oard (if you think those words are strong, go read the spreadsheet or maili= ng list!)

Oh, and of course, for completeness, we should describe= Camp #0, which didn't have any input in this feedback:

<= /div>
Camp #0: =C2=A0I've used SDP for years and I'm very comfo= rtable with it. =C2=A0Using SDP as the control surface really helps my use = case, which is legacy interop. =C2=A0Defining an API without SDP would be t= oo much work, and probably fail. =C2=A0Look at what happened with SDPng! = =C2=A0Supporting all these advanced use cases doesn't seem worth it. = =C2=A0 If developers are doing that much advanced stuff, they can learn to = munge SDP. =C2=A0It isn't that bad.=C2=A0

(By the way, I'm not a member of Camp #0, so I may = be a little off in my description of it. =C2=A0If any member of Camp #0 wou= ld like to adjust that description, please feel free).




Suggested Next Step: Figure= out what is needed for WebRTC++

As Cul= len recently pointed out, we need to get a list of things developers want t= o be able to control in a future version of the API which could hopefully m= ake developers happier Whether that future API is 1.0, 2.0, or 1.1 is an or= thogonal question, but let's call it WebRTC++ for now. =C2=A0 Clearly, = they want a way to control things without SDP, and perhaps without O/A at a= ll. =C2=A0But what do they want to control? =C2=A0We need a good list.

I suggest we reach out more closely to the developers, = and use their input to create not only a list of things they want to do, bu= t a WebRTC++ API that fulfills those needs without requiring SDP munging. = =C2=A0I think we can do this in parallel with the current =C2=A0API work wi= thout detracting from it (from the current work, that is). =C2=A0 =C2=A0Cer= tainly there is plenty of energy from people interested in working on it (W= ebRTC++, that is). =C2=A0Such parallel work would not only better capture t= he needs of developers, but could also improve the WebRTC (not ++) API =C2= =A0by incorporating ideas from it. =C2=A0

So far, such activity has been frowned on, perhaps out = of fear that it's a threat to the current work. =C2=A0But I think it ca= n be done in a way that doesn't threaten anything, and even learns from= and builds on the valuable input we are receiving from developers. =C2=A0T= he alternative is to ask all these developers to wait an indefinite amount = of time and munge SDP like crazy until then, and that seems like a rather p= oor answer. =C2=A0Therefore, I would support an exploratory effort at a &qu= ot;WebRTC++ API".





=

=C2=A0=C2=A0

--001a11c39d18cd80e304e1006c57-- From pthatcher@google.com Mon Jul 8 07:39:16 2013 Return-Path: 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 E68FA21F9CDF for ; Mon, 8 Jul 2013 07:39:16 -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, MIME_8BIT_HEADER=0.3, 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 Wua6vhRnaRNg for ; Mon, 8 Jul 2013 07:39:16 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C216621F9CEB for ; Mon, 8 Jul 2013 07:38:45 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so4165720pdj.17 for ; Mon, 08 Jul 2013 07:38:45 -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=WDGXvKcg1weCOctmDAP/9TEaCp2dmpkuian5sa7LJY8=; b=mrM2n9VDSsikihOW8qYs/QQ3gX2TqBxgpjZ3Ph2+k6MT7OT8X50pXPF0cWDfrJTH9v 8DVtc6KTdrK8XoUQnOu6vWlarYADzzMHRTnCJ7r2raNJcwb2AIYU3+PQr44EkMKkkZwp vT3accSvp5rfB9D+2wwfYQuXuS/aJ63F4OZ6TujpRANDNX/ct2IIxQv/45q1Q7vMh9mL ilnbSEJLZzdN+smSg0zsdYE/LugamDuBMiSYvF8Jj/3cSxCYl390O6fuK9ErIlF3dQCt TZB1k+3yycDhYP+N4ZQ3sCrNoyZSPyjmXJc1/GAU26EGDOQgDTBVuYrMPg3UpH7JcpwP If6Q== 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=WDGXvKcg1weCOctmDAP/9TEaCp2dmpkuian5sa7LJY8=; b=YvHQUDvbMs/UX5sioLAHwgnWYzZTOKq/gTsW2nRCLT+xkuyyEkFHW98NkdVFQshqT7 t1CxoOF55ZJqe6uBE/N1ogWfV02VPR+CkvqgYjZBoJA6sPWpzOHx+Hwg1SqNK5nxh/Io +WcmDAI48zSkKNwLZEBNdWf8NEk0jjyQZop/ThJi4aOL37dE01UYcYQHv6j58hpFDtes e6tYGY4JDcfDdp0+C+YfT3zSfHcZCF3Aj06dfnI+Gcjhp8fkwOhtx0+14aagrRCzXqsd sjeYK44TtS6Er4dhyYRFF4HKrbqF0lYqkbNRxiiG3LLHR2LKWvDfY+57dOict0XeKy0a 0nRw== X-Received: by 10.66.14.196 with SMTP id r4mr23540689pac.57.1373294325358; Mon, 08 Jul 2013 07:38:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 07:38:05 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Mon, 8 Jul 2013 07:38:05 -0700 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=bcaec51f99e56fabd204e10100c5 X-Gm-Message-State: ALoCoQm+7J1USveCwcq1ZnK+RS2tkhEsygZYigM33CySV1DuHq23TFZvZUGxkFrARdzh/xQdNc266YHA8rTcRSpncpdLgaqFtlX6vF6xaBUUDplfHp7ZZvIKR+e6B4T29vVwOY1LFt1dW96BWmaE1y9PMicczbAzN053NimxjbKnCujuirAlhG/nUpQNlvNof88T0ys/M+Iv Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:39:17 -0000 --bcaec51f99e56fabd204e10100c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 8, 2013 at 5:11 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 7/7/13 11:14 PM, Roman Shpount wrote: > > > > On Sat, Jul 6, 2013 at 2:33 AM, Stefan H=C3=A5kansson LK > > > > wrote: > > > > On 7/3/13 11:37 PM, Eric Rescorla wrote: > > > I'm glad to be wrong here. Is the phrase "you shouldn't hav= e > to > > > modify the SDP but rather there should be API points to cove= r > > most > > > of the use cases" the consensus of the working group? > > > > > > > > > I thought it was, but I'm not the chair, so maybe you could ask > > Harald or > > > Stefan. > > > > I definitely think this is the consensus of the working group. > > > > > > Can you point out when exactly this consensus was reached? This is news > > to me, but I definitely could have missed something. > > No I can't really. To be clear, no consensus call (or similar) has been > held. But every time this is discussed, what I hear is people agreeing > and no objections. It was discussed a bit, e.g., at the f2f at TPAC last year, if you read the minutes [1] you will find some traces of that > discussion. > No objections at all? That is rather surprising to me. I asked for some feedback the API in the spreadsheet from web developers, at there many objections from them about this part of the API. A majority did say it was good enough for simple use cases, but he objections were still clearly non-zero. I think perhaps the web developers are not well represented at TPAC. But I could be wrong. Perhaps they are but changed their mind. Or maybe they're objecting on the IETF mailing list when they should object on the IETF mailing list. Or maybe the spreadsheet has a sample bias, while TPAC is the true sample. I don't know, but it seems like something is going on, and I'd like to know what it is. Stefan, what do you think? What could explain the apparent contradiction between objections on the mailing list vs. no objections f2f? Also, on discussions about the API, should those who want to propose additions (such as the NoPlan JS API I proposed) and other comments put them on the W3C mailing list instead of the IETF one? Is everyone barking up the wrong tree? Thanks in advance for your input. > And, I don't understand why there would be a debate about this. There > are obviously many who want to define APIs (or constraints) that allow > most use-cases to be met without having to modify the SDP. Why would anyone have anything against that? I think your question actually has two questions: 1. Is anyone against making additions to the API to avoid SDP munging? 2. Why are they against additions to the API to avoid SDP munging? My personal experience for #1 is that there are some notable people in the WG who are very much against making additions to the API to avoid SDP munging. Some of them are rather upset with me for proposing a few minor additions to the API (the NoPlan JS API) precisely because it allows the JS to go around the SDP in many cases, and they don't like that. So, from my experience, it's clear that the answer to #1 is "yes, many do". And since many object to such additions, and others want such additions, you end up with debate. How about #2? Why do they object? My experience is that they view any additions as a threat to API as a threat to the current API, which means it's a threat to the current WG progress, which means it's a threat to getting done. They are very sensitive to such threats, and so object to any additions or changes that would allow JS to avoid using SDP. Also, I think they don't want to ways of doing things, so SDP must remain the one true way. But that's just my personal experience and perspective. I could just be seeing it wrong, or maybe the only person experiencing this. > I If there is anyone who really wants > to modify the SDP instead (I have no clue why, but anyway) they can > still do that. > Well, no one is going to hit themselves in the head with a hammer if they don't have to, but there are many uses cases that currently be done only by SDP munging, and I don't see any API additions on the horizon that will help those uses cases. So, until we can agree on some API additions that help SDP munging, many web developers are going to have to keep swinging that hammer, no matter how much it hurts. But clearly, if you gave them an API that didn't require such pain, they would use it. > > [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Nov/0072.html > > > _____________ > > Roman Shpount > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec51f99e56fabd204e10100c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 8, 2013 at 5:11 AM, Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
On 7/7/13 11:14 PM, Roman Shpount wrote:=
>
> On Sat, Jul 6, 2013 at 2:33 AM, Stefan H=C3=A5kansson LK
> <stefan.lk.haka= nsson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
> =C2=A0 =C2=A0 On 7/3/13 11:37 PM, Eric Rescorla wrote:
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 I'm glad to be wrong here. = =C2=A0Is the phrase "you shouldn't have to
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 modify the SDP but rather there= should be API points to cover
> =C2=A0 =C2=A0 most
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 of the use cases" =C2=A0th= e consensus of the working group?
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> I thought it was, but I'm not the chair, = so maybe you could ask
> =C2=A0 =C2=A0 Harald or
> =C2=A0 =C2=A0 =C2=A0> Stefan.
>
> =C2=A0 =C2=A0 I definitely think this is the consensus of the working = group.
>
>
> Can you point out when exactly this consensus was reached? This is new= s
> to me, but I definitely could have missed something.

No I can't really. To be clear, no consensus call (or similar) ha= s been
held. But every time this is discussed, what I hear is people agreeing
and no objections. =C2=A0It was discussed a bit, e.g., at the f2f at TPAC l= ast
year, if you read the minutes [1] you will find some traces of that
discussion.

No objections at all? =C2= =A0That is rather surprising to me. =C2=A0I asked for some feedback the API= in the spreadsheet from web developers, at there many objections from them= about this part of the API. =C2=A0A majority did say it was good enough fo= r simple use cases, but he objections were still clearly non-zero.=C2=A0

I think perhaps the web developers are not well represe= nted at TPAC. =C2=A0But I could be wrong. =C2=A0Perhaps they are but change= d their mind. =C2=A0Or maybe they're objecting on the IETF mailing list= when they should object on the IETF mailing list. =C2=A0 Or maybe the spre= adsheet has a sample bias, while TPAC is the true sample. =C2=A0 I don'= t know, but it seems like something is going on, and I'd like to know w= hat it is.

Stefan, what do you think? =C2=A0What could explain the= apparent contradiction between objections on the mailing list vs. no objec= tions f2f?


Also, on discussions abo= ut the API, should those who want to propose additions (such as the NoPlan = JS API I proposed) and other comments put them on the W3C mailing list inst= ead of the IETF one? =C2=A0Is everyone barking up the wrong tree?

Thanks in advance for your input.

<= div>



And, I don't understand why there would be a debate about this. There are obviously many who want to define APIs (or constraints) that allow
most use-cases to be met without having to modify the SDP. =C2=A0Why would<= /blockquote>
anyone have anything against that?=C2=A0

I think your question actually has two questions:

1. =C2=A0Is anyone against making additions to the API to avoid SDP mung= ing? =C2=A0

2. =C2=A0Why are they against additions to the API to a= void SDP munging?


My personal exper= ience for #1 is that there are some notable people in the WG who are very m= uch against making additions to the API to avoid SDP munging. =C2=A0Some of= them are rather upset with me for proposing a few minor additions to the A= PI (the NoPlan JS API) precisely because it allows the JS to go around the = SDP in many cases, and they don't like that. =C2=A0So, from my experien= ce, it's clear that the answer to #1 is "yes, many do".=C2=A0=

And since many object to such additions, and others wan= t such additions, you end up with debate. =C2=A0

<= br>
How about #2? =C2=A0Why do they object? =C2=A0My experience i= s that they view any additions as a threat to API as a threat to the curren= t API, which means it's a threat to the current WG progress, which mean= s it's a threat to getting done. =C2=A0They are very sensitive to such = threats, and so object to any additions or changes that would allow JS to a= void using SDP. =C2=A0Also, I think they don't want to ways of doing th= ings, so SDP must remain the one true way.


But that's just my personal experien= ce and perspective. =C2=A0I could just be seeing it wrong, or maybe the onl= y person experiencing this.




=C2=A0
I If there is anyone who really= wants
to modify the SDP instead (I have no clue why, but anyway) they can
still do that.

Well, no one is going to= hit themselves in the head with a hammer if they don't have to, but th= ere are many uses cases that currently be done only by SDP munging, and I d= on't see any API additions on the horizon that will help those uses cas= es. =C2=A0 =C2=A0So, until we can agree on some API additions that help SDP= munging, many web developers are going to have to keep swinging that hamme= r, no matter how much it hurts.

But clearly, if you gave them an API that didn't re= quire such pain, they would use it.

=C2=A0

[1] http://lists.w3.org/Archives/Public/public-webrt= c/2012Nov/0072.html

> _____________
> Roman Shpount
>

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

--bcaec51f99e56fabd204e10100c5-- From pthatcher@google.com Mon Jul 8 07:40:45 2013 Return-Path: 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 BB65821F9A40 for ; Mon, 8 Jul 2013 07:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.017, 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 coVEXCzPbfBd for ; Mon, 8 Jul 2013 07:40:45 -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 5AA7421F9349 for ; Mon, 8 Jul 2013 07:40:45 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so4441525pad.16 for ; Mon, 08 Jul 2013 07:40:45 -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=TaeoURjcdglh2Zx5VHhBjPEiv8c/aIvAMu1qzY2n8Zs=; b=WdypH5rnQBJID7atbVX++5b0UR/6yys1fNdZ7y8HDRliFcoFN25a3nNrRjhOPRz77k MS35JQEoSCPTSjhOYjbOmY/1ljx08LxjPGK1HOt4m5HhtyJBFHOpjV3uF8iM3EmgpcBV nsyk7QXwGf15TI7oMWWyd2y9nAYeXFSpY2Y3Qe7qgn6ltDTNzQZItfP+tnM77yTMjv+n QcVDKprf2XiNP+8EkZqgG919K6pCp9SiE1WICQhFbYuFR7mQbZcg94+TjhkRbcg8BDaM AWCYR8n9UG9PFob6iXXFQuz6tumkOQMTI7DoufybWsg6ys8+JnzI9mmmWxHb24nSotYU H/+w== 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=TaeoURjcdglh2Zx5VHhBjPEiv8c/aIvAMu1qzY2n8Zs=; b=YakhspBFYH1hXVNrXwrzIkxgaZI26FLLopHXb3Mjm/ippFWqCdOpRoRrBv8PGtJ7PX CC7JJwtbu12ahDXHl8dNZUEh9OAK2n3VUAvhd4Onl0YuJQv10OGT2L/kvir4rJjm2POL CeWRvkhZM298hvIqoYVBZeOLbL+AThHwQWw+bbHfr/1BpTqIfLvTPp/RQAjqJNgSnleq 9B5b7YOU0lkWzOfk4OzL2sft3uhxNvADXc4x1XnmPxxBiyJnr86cZD6EZu61LR40Oncs mgQAZhkD/TURjL60K0MfL6bQQhdrMEXTax/Q3C2wOCacSm2SB/ZNHUNAH+D56MSWduL2 ch2A== X-Received: by 10.68.28.232 with SMTP id e8mr21892783pbh.94.1373294444983; Mon, 08 Jul 2013 07:40:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 07:40:04 -0700 (PDT) In-Reply-To: <8B58E2AB-09B7-4816-8BC4-B932030E2ED2@iii.ca> References: <8B58E2AB-09B7-4816-8BC4-B932030E2ED2@iii.ca> From: Peter Thatcher Date: Mon, 8 Jul 2013 07:40:04 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=bcaec520eacd90d6bd04e101070c X-Gm-Message-State: ALoCoQlcSjlkOPXt4ZCQ6Xv9Zs+lp3QJ4NyCFoXInOkm5UMdVhfQ4F7DFkDUwaqSdc1pIR6RjqxVVwCwOED/oVIEoJD+qWmWOdiu9F0g1gJF33SDnEAvFhO5+bl3WS9TM38oZk1FyBSHu3c9w1BaoaHRDKbhDbDh1kAIOhK8eAONUDPncM3ezfu4+xCqiTmN4b3s81mu09ZV Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:40:45 -0000 --bcaec520eacd90d6bd04e101070c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jul 7, 2013 at 8:40 PM, Cullen Jennings wrote: > > On Jul 3, 2013, at 2:42 PM, I=C3=B1aki Baz Castillo wrote= : > > > So compatibility with SIP is important but compatibility with Jingle is > just impossible. > > The mapping of SDP to jingle is in the Jingle specs =E2=80=A6 I'm not exp= ress any > opinion on this one way or another other but the authors of theses specs > have always claimed Jingle fully mapped to and from SDP. > I think he meant "impossible without SDP munging", which I think is undeniable. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec520eacd90d6bd04e101070c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 7, 2013 at 8:40 PM,= Cullen Jennings <fluffy@iii.ca> wrote:

On Jul 3, 2013, at 2:42 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

> So compatibility with SIP is important but compatibility with Jingle i= s just impossible.

The mapping of SDP to jingle is in the Jingle specs =E2=80=A6 I'm= not express any opinion on this one way or another other but the authors o= f theses specs have always claimed Jingle fully mapped to and from SDP.
=

I think he meant "impossible without SDP munging",= which I think is undeniable.

= =C2=A0


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

--bcaec520eacd90d6bd04e101070c-- From stpeter@stpeter.im Mon Jul 8 07:45:33 2013 Return-Path: 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 DFFB521F9A51 for ; Mon, 8 Jul 2013 07:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qQu5gsANmtGs for ; Mon, 8 Jul 2013 07:45:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9CE21F924A for ; Mon, 8 Jul 2013 07:45:27 -0700 (PDT) Received: from sjc-vpn5-1558.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CAE2D4011B; Mon, 8 Jul 2013 08:46:24 -0600 (MDT) Message-ID: <51DAD083.8000901@stpeter.im> Date: Mon, 08 Jul 2013 08:45:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Thatcher References: <8B58E2AB-09B7-4816-8BC4-B932030E2ED2@iii.ca> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:45:34 -0000 On 7/8/13 8:40 AM, Peter Thatcher wrote: > On Sun, Jul 7, 2013 at 8:40 PM, Cullen Jennings > wrote: > > > On Jul 3, 2013, at 2:42 PM, Iñaki Baz Castillo > wrote: > > > So compatibility with SIP is important but compatibility with > Jingle is just impossible. > > The mapping of SDP to jingle is in the Jingle specs … I'm not > express any opinion on this one way or another other but the authors > of theses specs have always claimed Jingle fully mapped to and from SDP. > > > I think he meant "impossible without SDP munging", which I think is > undeniable. What do you mean by "SDP munging"? As we know, various things are being added to SDP. The Jingle specs have not necessarily been updated yet to track those changes, although proposals have been made on several points. If folks want to keep Jingle in sync, that work would need to happen at the XSF. Feel free to join the jingle@xmpp.org list if you have proposals: http://mail.jabber.org/mailman/listinfo/jingle Peter -- Peter Saint-Andre https://stpeter.im/ From pthatcher@google.com Mon Jul 8 07:48:42 2013 Return-Path: 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 06A2821F9CE7 for ; Mon, 8 Jul 2013 07:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.015, 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 rbq8be0cKMfF for ; Mon, 8 Jul 2013 07:48:41 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 39C9C21F9815 for ; Mon, 8 Jul 2013 07:48:41 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 10so4158402pdc.19 for ; Mon, 08 Jul 2013 07:48:40 -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=1TG2mUrqV3WcdoJ3xXa68POk+nT6nSrXzNA799IVAJY=; b=bQL1UfBhVy7kIo8lL3C6nfkwpajihcr3+IkmLt32YXIqOYSuBqlxi8D7FlqWHfAvV2 cvnnzi9mciomzuDfUVz2ca3s6nINUY24JawkaNCOvhfC8yMRrGiRHDgMM50Q76CPrpwZ 67GNia7EGHuGS4hKmdyU9ekjbe6VBbfIVW/bdU5kHqkkj4o374hiQNieHS6jJjTAZS9E CpZFoDp0VaF0ZoeXBwpAiZ1IwHGi7hnqbdVCcdBGe9j5jJU9jISRR0rEz5UG2pZatOz8 gNkh2OBjwRIJnP+36+HWl4YCgJoApylVvgFDsLofqYW5RGxFGkLYV7Q3EnBJBxUqN7RX BPBg== 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=1TG2mUrqV3WcdoJ3xXa68POk+nT6nSrXzNA799IVAJY=; b=G7u7dSZzqoWmDHDl6K5MDyKk54XSQv8iBO1BEuDL1xax7WeMDzf/UbHMVQhRLFqf7t ZdZHIlDUJIzvBWoabNxyQTS+AQxXvne+m6UbTldtmXbm2TG2GvnBmLedg7e/wz9p4Raw ZHHuEDmmi63hsl9wxdApDJVd9l+/b/2/248wAi7ClRXRCcShLpN6r10UiDaDWkCH2PpF RRIwCB3S+I/TVaek/4Uefy5yJfYWSS3OEVIUslB2jq7SRaHhpNMZd2b42yj5l2AsYot6 9ZuruIGNKLfa27LG3KCoEkqtGGCteHpBGG9T01JlkoKIy1R406vuIV0tZpCaLIltnLps j9iQ== X-Received: by 10.68.28.232 with SMTP id e8mr21924703pbh.94.1373294920829; Mon, 08 Jul 2013 07:48:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 07:47:59 -0700 (PDT) In-Reply-To: <51DAD083.8000901@stpeter.im> References: <8B58E2AB-09B7-4816-8BC4-B932030E2ED2@iii.ca> <51DAD083.8000901@stpeter.im> From: Peter Thatcher Date: Mon, 8 Jul 2013 07:47:59 -0700 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=bcaec520eacdedb8f904e1012343 X-Gm-Message-State: ALoCoQk9W3U1oVi3UDGwN1C0lraRcu3Re+EqQCrnqbVW5EiqtjDle73k2pkjMKYkNpV6fY04q8lVXb7scHwYuzYEQAVRxd3KEqh3vvMKmbjYafYcwaIOF1TJwxBQbALl/GQw+NCWofjSJRNhUsbJ6higsU+TE7mbwYxw9EQZ/fUoEKIv3XUEmd29HPm+qLBmZmdnoBi0h38H Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:48:42 -0000 --bcaec520eacdedb8f904e1012343 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 8, 2013 at 7:45 AM, Peter Saint-Andre wrote= : > On 7/8/13 8:40 AM, Peter Thatcher wrote: > > On Sun, Jul 7, 2013 at 8:40 PM, Cullen Jennings > > wrote: > > > > > > On Jul 3, 2013, at 2:42 PM, I=C3=B1aki Baz Castillo > > wrote: > > > > > So compatibility with SIP is important but compatibility with > > Jingle is just impossible. > > > > The mapping of SDP to jingle is in the Jingle specs =E2=80=A6 I'm n= ot > > express any opinion on this one way or another other but the author= s > > of theses specs have always claimed Jingle fully mapped to and from > SDP. > > > > > > I think he meant "impossible without SDP munging", which I think is > > undeniable. > > What do you mean by "SDP munging"? > I mean that if the JS wants to send Jingle XML over the wire, it has to parse the SDP. Then, when it receives Jingle XML, it has to serialize SDP. That parsing and serializing of SDP I call "munging". We could come up with better words for more specific activities, but that seems to be the word everyone else uses, so it's what I've used. > > As we know, various things are being added to SDP. The Jingle specs have > not necessarily been updated yet to track those changes, although > proposals have been made on several points. If folks want to keep Jingle > in sync, that work would need to happen at the XSF. Feel free to join > the jingle@xmpp.org list if you have proposals: > > http://mail.jabber.org/mailman/listinfo/jingle > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > --bcaec520eacdedb8f904e1012343 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 8, 2013 at 7:45 AM, Peter Saint-Andre <stpeter@stpete= r.im> wrote:
On 7/8/13 8:40 AM, Peter T= hatcher wrote:
> On Sun, Jul 7, 2013 at 8:40 PM, Cullen Jennings <fluffy@iii.ca
> <mailto:fl= uffy@iii.ca>> wrote:
>
>
> =C2=A0 =C2=A0 On Jul 3, 2013, at 2:42 PM, I=C3=B1aki Baz Castillo <= ibc@aliax.net
> =C2=A0 =C2=A0 <mailto:ibc@aliax.net>> wrote:
>
> =C2=A0 =C2=A0 > So compatibility with SIP is important but compatib= ility with
> =C2=A0 =C2=A0 Jingle is just impossible.
>
> =C2=A0 =C2=A0 The mapping of SDP to jingle is in the Jingle specs =E2= =80=A6 I'm not
> =C2=A0 =C2=A0 express any opinion on this one way or another other but= the authors
> =C2=A0 =C2=A0 of theses specs have always claimed Jingle fully mapped = to and from SDP.
>
>
> I think he meant "impossible without SDP munging", which I t= hink is
> undeniable.

What do you mean by "SDP munging"?
I mean that if the JS wants to send Jingle XML over the wire, i= t has to parse the SDP. =C2=A0Then, when it receives Jingle XML, it has to = serialize SDP. =C2=A0 That parsing and serializing of SDP I call "mung= ing". =C2=A0We could come up with better words for more specific activ= ities, but that seems to be the word everyone else uses, so it's what I= 've used.


=C2=A0

As we know, various things are being added to SDP. The Jingle specs have not necessarily been updated yet to track those changes, although
proposals have been made on several points. If folks want to keep Jingle in sync, that work would need to happen at the XSF. Feel free to join
the jingle@xmpp.org list if you have= proposals:

http://mail.jabber.org/mailman/listinfo/jingle

Peter

--
Peter Saint-Andre
https://stpeter.im/


--bcaec520eacdedb8f904e1012343-- From pthatcher@google.com Mon Jul 8 07:51:54 2013 Return-Path: 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 03A4221F9C06 for ; Mon, 8 Jul 2013 07:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 3rJV-6NCMQwl for ; Mon, 8 Jul 2013 07:51:53 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2A91C21F9AA4 for ; Mon, 8 Jul 2013 07:51:53 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id xb12so4351612pbc.40 for ; Mon, 08 Jul 2013 07:51:52 -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=xOukynzRt9DJpE6XRhuAl6Om2WTAN9tE9ZQxh1of5R8=; b=PFIm/zNYQqw7PBcz0NrEeBwLJsHS53VeFjXVuB7JXRhHCvslC7gpI+O4fvps0mcmHR RL1eo3cGIuyXRd3AvdEx8huMysJHvdaDRwon1+hILWYoq2/PHeFjKSuMlYRTv4FxUJsC 3yuJMVCd2nGc3BRrqaAsti5ih+9e/Wd0hDmQJgxChEEfRly1e3hGrAFWQ2X1ABEvJUY6 TBbY1BR+RwUZECv74Bemw+B9DlBbW26QvALj8lP2bUhV88JgujYNaFlmOqX21wn00e3s 433EGrbiGhZkuOHgTlhMwoIAwWegMz3hG9Lx+scEJ7DxzfBX4FFhVkO2j2lBxymq8Bi7 ezgQ== 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=xOukynzRt9DJpE6XRhuAl6Om2WTAN9tE9ZQxh1of5R8=; b=pfbEbgJU6b/grO00NgPFgHkSUmT2J06i/622pnLJKstjllwhucHJKoyKJUhh6m+zHS Zk7QMLq4JrzGAR2uvNIqgkLVfL77NfwjItJ+ADlNNnSjqu1eQN6ZbKKuik/Vtoe8C4hX 0AzPcARxrb/r4881ml+zAazCEEfLYnFm1Ov5EUFu/8w+JAif5H2Ce6PkEjlgs6V7ThqA qyyQjXJEDnystb3c96lAyXC2/eiTGdOADTaGtTYRJztp0sEbi8z+sJw5Z0Mt8Ll/KiJu GJqWnFRnDEFR5z3D+ZCdLTiSwtQfreRcSnl9AMr3EM3zHqCVvSY1kYfWIudcF9o4sX/e agRA== X-Received: by 10.66.25.10 with SMTP id y10mr23059589paf.96.1373295112634; Mon, 08 Jul 2013 07:51:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 07:51:12 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Mon, 8 Jul 2013 07:51:12 -0700 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=bcaec52bec175cb2ef04e1012f51 X-Gm-Message-State: ALoCoQm3hsauhnimkmQT/SGsnJrTFc2vuAUCC8jwCXIzkH8UcS5eETWtzsU7QNfe/X5a1I4heeoEPDYWwI31VoOSqfHzGCSXE1Q7FXLATqIze9KUYCise4Dc+ub9tcnv5BdnSjLoU7OqRBGKOKDZrErOm4pH5VjbsFS8RhEoUk8Xpsck1HeyVikBbfDY8QkibxWipspEYvIx Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:51:54 -0000 --bcaec52bec175cb2ef04e1012f51 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 5, 2013 at 11:33 PM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 7/3/13 11:37 PM, Eric Rescorla wrote: > > On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher > > wrote: > > > > On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla > > wrote: > > > > On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher > > > wrote: > > > > Camp #0: I've used SDP for years and I'm very comfortable > > with it. Using SDP as the control surface really helps my > > use case, which is legacy interop. Defining an API without > > SDP would be too much work, and probably fail. Look at wha= t > > happened with SDPng! Supporting all these advanced use > > cases doesn't seem worth it. If developers are doing that > > much advanced stuff, they can learn to munge SDP. It isn't > > that bad. > > > > > > Hmm... That's not my understanding of the situation at all. > > > > Rather, I believe the expectation is that you shouldn't have to > > modify the > > SDP but rather there should be API points to cover most of the > > use cases > > that people want. This isn't to say that all those API points > > exist or that > > they work or whatever. > > > > -Ekr > > > > > > I'm glad to be wrong here. Is the phrase "you shouldn't have to > > modify the SDP but rather there should be API points to cover most > > of the use cases" the consensus of the working group? > > > > > > I thought it was, but I'm not the chair, so maybe you could ask Harald = or > > Stefan. > > I definitely think this is the consensus of the working group. > > I think the exception would be when interoperating with other systems > that use another dialect of SDP - I don't think we could cover such > translations with API points. > Are you trying to say "API points couldn't cover uses cases where different dialects of SDP go over the wire"? Because I would have to disagree with that. I think we could very easily support such uses cases with rather minor changes to the API. In fact, the proposal I made for adding just 3 methods (the NoPlan JS API) allows for either Plan A or Plan B (or even Jingle, mostly), which would make things a lot easier for such use cases. Now, my design might not be the optimal. Perhaps we could do better. But I think it is possible to serve all these uses cases with a pleasant API. > > > > > > > Along with that, is "use Jingle for signalling" included in your se= t > > of "most of the use cases"? > > > > > > No, I don't think it is, since it's not SDP. > > > > Maybe I could phrase this differently: It was my understanding that you > > should have > > API points to get the PC to emit SDP that would express the policies, > > preferences, > > actions, etc. that the application wants. If you want something that's > > not SDP you would > > need to gateway. > > > > This may or may not be a satisfactory state of affairs, but it was the > > rule I was using > > (based on what I thought the WG expected) for when use cases needed new > API > > points. > > > > -Ekr > > > > --bcaec52bec175cb2ef04e1012f51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 5, 2013 at 11:33 PM, Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
On 7/3/13 11:37 PM, Eric R= escorla wrote:
> On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher <pthatcher@google.com
> <mailto:pthatcher@google.com>> wrote:
>
> =C2=A0 =C2=A0 On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla <ekr@rtfm.com
> =C2=A0 =C2=A0 <mailto:ekr@rtfm.com>> wrote:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Wed, Jul 3, 2013 at 2:06 PM, Peter That= cher
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <pthatcher@google.com <mailto:pthatcher@google.com>> wrote:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Camp #0: =C2=A0I've used= SDP for years and I'm very comfortable
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with it. =C2=A0Using SDP as = the control surface really helps my
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use case, which is legacy in= terop. =C2=A0Defining an API without
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP would be too much work, = and probably fail. =C2=A0Look at what
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 happened with SDPng! =C2=A0S= upporting all these advanced use
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cases doesn't seem worth= it. =C2=A0 If developers are doing that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 much advanced stuff, they ca= n learn to munge SDP. =C2=A0It isn't
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that bad.
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hmm... That's not my understanding of = the situation at all.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Rather, I believe the expectation is that = you shouldn't have to
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 modify the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP but rather there should be API points = to cover most of the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 use cases
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 that people want. This isn't to say th= at all those API points
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 exist or that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 they work or whatever.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -Ekr
>
>
> =C2=A0 =C2=A0 I'm glad to be wrong here. =C2=A0Is the phrase "= ;you shouldn't have to
> =C2=A0 =C2=A0 modify the SDP but rather there should be API points to = cover most
> =C2=A0 =C2=A0 of the use cases" =C2=A0the consensus of the workin= g group?
>
>
> I thought it was, but I'm not the chair, so maybe you could ask Ha= rald or
> Stefan.

I definitely think this is the consensus of the working group.

I think the exception would be when interoperating with other systems
that use another dialect of SDP - I don't think we could cover such
translations with API points.

Are you t= rying to say "API points couldn't cover uses cases where different= dialects of SDP go over the wire"? =C2=A0Because I would have to disa= gree with that. =C2=A0I think we could very easily support such uses cases = with rather minor changes to the API. =C2=A0In fact, the proposal I made fo= r adding just 3 methods (the NoPlan JS API) allows for either Plan A or Pla= n B (or even Jingle, mostly), which would make things a lot easier for such= use cases. =C2=A0

Now, my design might not be the optimal. =C2=A0Perhaps = we could do better. =C2=A0But I think it is possible to serve all these use= s cases with a pleasant API.



>
>
> =C2=A0 =C2=A0 Along with that, is "use Jingle for signalling"= ; included in your set
> =C2=A0 =C2=A0 of "most of the use cases"?
>
>
> No, I don't think it is, since it's not SDP.
>
> Maybe I could phrase this differently: It was my understanding that yo= u
> should have
> API points to get the PC to emit SDP that would express the policies,<= br> > preferences,
> actions, etc. that the application wants. If you want something that&#= 39;s
> not SDP you would
> need to gateway.
>
> This may or may not be a satisfactory state of affairs, but it was the=
> rule I was using
> (based on what I thought the WG expected) for when use cases needed ne= w API
> points.
>
> -Ekr
>


--bcaec52bec175cb2ef04e1012f51-- From fippo@goodadvice.pages.de Mon Jul 8 07:54:29 2013 Return-Path: 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 762F921F9D19 for ; Mon, 8 Jul 2013 07:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 vZgpll5M1CRE for ; Mon, 8 Jul 2013 07:54:21 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 66B3521F9C86 for ; Mon, 8 Jul 2013 07:54:10 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r68Es4xj019746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jul 2013 16:54:04 +0200 Received: from localhost (fippo@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) with ESMTP id r68Es4st019742; Mon, 8 Jul 2013 16:54:04 +0200 X-Authentication-Warning: lo.psyced.org: fippo owned process doing -bs Date: Mon, 8 Jul 2013 16:54:04 +0200 (CEST) From: Philipp Hancke X-X-Sender: fippo@lo.psyced.org To: Peter Thatcher In-Reply-To: Message-ID: References: <8B58E2AB-09B7-4816-8BC4-B932030E2ED2@iii.ca> <51DAD083.8000901@stpeter.im> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="683466026-694137549-1373295244=:19554" Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:54:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --683466026-694137549-1373295244=:19554 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 8 Jul 2013, Peter Thatcher wrote: > >     > So compatibility with SIP is important but compatibility with > >     Jingle is just impossible. > > > >     The mapping of SDP to jingle is in the Jingle specs ? I'm not > >     express any opinion on this one way or another other but the authors > >     of theses specs have always claimed Jingle fully mapped to and from SDP. > > > > > > I think he meant "impossible without SDP munging", which I think is > > undeniable. > > What do you mean by "SDP munging"? > > > I mean that if the JS wants to send Jingle XML over the wire, it has to parse the SDP.  Then, when it receives Jingle XML, it has to serialize SDP.   That parsing and serializing of SDP I call "munging".  We could come up with better words for more specific > activities, but that seems to be the word everyone else uses, so it's what I've used. I think "mangle" is a better term here. People who want to do jingle are aware of the fact that this is more difficult than running their own proprietary stuff over xml. Or use SoX :-) --683466026-694137549-1373295244=:19554-- From pthatcher@google.com Mon Jul 8 07:55:48 2013 Return-Path: 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 65A1A21F9B0E for ; Mon, 8 Jul 2013 07:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.025, 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 MXyjNVbYwbyQ for ; Mon, 8 Jul 2013 07:55:47 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 65D4B21F995F for ; Mon, 8 Jul 2013 07:55:18 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v14so4143574pde.18 for ; Mon, 08 Jul 2013 07:55:12 -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=Mp2SWVSrDJYTw3tl8sSbekNw5jLuYCfdzIaQismCkx4=; b=KeMOev7MIEsLbHLk0Q7Of+v++NBsePRXFYSzj9j37st2t1jkUTlWbDKVODEUCCXUVL VH/A0HDxhel8cAFLvQ1395PGlANpP3UI2/HxEhVmBCLb21zSzhBPmt4ox/uCrDeQVtA6 XnpkO5+f2BMC1NiGtXUH7R623cr+FpP1n1p7XihooQfcMryfMXYZYz6IRrHUkkkB34yK TrP4L1QgCeoFsIEjgXsJXwXSg820zmtzuu5bMteDInix1Cjc88hZwdmCMI/mA/AnJEyC 9AN+WLxCOrgJA4I5kB4MFVprdWpdIhg543lslm4y71R+I/I9fgJjX2inb3/0Sjop3P6/ Gp/w== 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=Mp2SWVSrDJYTw3tl8sSbekNw5jLuYCfdzIaQismCkx4=; b=NY8RDAoh959HzQm7PknCgY84jO6lSvzkojkT8X6M4cLUsKKOfclZ3GIZtNYdSw0XI0 pN5ap0C04bb/YL0R2ccBODNQozLtVlg/f71GhyuH8bsyq5HIZMmbS62kEG+VUnmwGndP x13Lbf8kZJIo1f1NKvU0Z3xSKlIe/mXLZE4EkeVHpkhWw13BrFHu/+u2h46tG0exVXus DbWAqL8t/N3PupDPtDZBr/g//bfvDM6o9oCPQXZeIn6h6E/qCKPfmqibENJFuTfJkIqv t85T4Dl/kq96tQJfiou6bky8kxGvO/5YR4D2ToG+Zv7ovnu2DTJXdza68tNKHlEPf/CD mAjw== X-Received: by 10.66.217.195 with SMTP id pa3mr23423977pac.120.1373295312751; Mon, 08 Jul 2013 07:55:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 07:54:32 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Mon, 8 Jul 2013 07:54:32 -0700 Message-ID: To: Philipp Hancke Content-Type: multipart/alternative; boundary=047d7b5d438c4a07f404e1013b6a X-Gm-Message-State: ALoCoQlRsnCLLkZMvVmVfW6rMpnOdu4ymmHAJ6U8bksNugZ1TFI2Bvy6ErotZZAuIQ2DN3bDHtI/Ybt5qp8zveC57PH6iyVuCVSDqfl0ntJoB6q0HghZpIOX3yGBq39MjGMpJN5aHM1x3BCizDWxyo1m3zuE/UuHloSlyM7uQT1RLyx7YWdFJjBNUNFo0bWGUkikmfy+p2cN Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:55:48 -0000 --047d7b5d438c4a07f404e1013b6a Content-Type: text/plain; charset=UTF-8 On Wed, Jul 3, 2013 at 11:35 PM, Philipp Hancke wrote: > On Wed, 3 Jul 2013, Eric Rescorla wrote: > >> Who said anything about impossible? It's a mechanical transformation >> (see: http://xmpp.org/**extensions/xep-0167.html >> ). >> > > That is true for simple usage and works reasonably well. See my > strophe.jingle code on github. I'd note that I want to revamp > the API such that it wraps the peerconnections SDP apis more closely. > > Things like the content-add/content-remove are harder because the API user > is required to calculate an SDP delta/diff. The appendix A.1.3 of the JSEP > draft calls this createContentAdd, parseContentAdd, createContentAccept and > parseContentAccept. Has anyone ever implemented those operations in > javascript and can demonstrate running code? > I think those were added about a week ago. Both Chrome and Firefox try to update quickly, but that would be amazing! > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b5d438c4a07f404e1013b6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 3, 2013 at 11:35 PM, Philipp Hancke &= lt;fippo@goo= dadvice.pages.de> wrote:
On Wed, 3 Jul 2013, Eric R= escorla wrote:
Who said anything about impossible? It's a mechanical transformation (see:=C2=A0http://xmpp.org/extensions/xep-0167.html).

That is true for simple usage and works reasonably well. See my
strophe.jingle code on github. I'd note that I want to revamp
the API such that it wraps the peerconnections SDP apis more closely.

Things like the content-add/content-remove are harder because the API user = is required to calculate an SDP delta/diff. The appendix A.1.3 of the JSEP = draft calls this createContentAdd, parseContentAdd, createContentAccept and= parseContentAccept. Has anyone ever implemented those operations in javasc= ript and can demonstrate running code?

I think those were added about a week ago.= =C2=A0Both Chrome and Firefox try to update quickly, but that would be ama= zing!
=C2=A0
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b5d438c4a07f404e1013b6a-- From pthatcher@google.com Mon Jul 8 07:56:58 2013 Return-Path: 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 9999621F9D53 for ; Mon, 8 Jul 2013 07:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.023, 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 sYtUvgbjBNTx for ; Mon, 8 Jul 2013 07:56:58 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA1521F9D4B for ; Mon, 8 Jul 2013 07:56:53 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w11so4182728pde.37 for ; Mon, 08 Jul 2013 07:56:53 -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=mJ07ciWiBLzJ+zvyi87SFzZlLJ47JWnJIRmtDCBPdJ4=; b=aLCO95B+72lGMwN+a0Mfrt7K3AxqesknGd5shLMGvxpF0lC0vb7eL+typnHDdFKL3Y QCHBAbMjFfYyjeCuYUjhWAcs+XSK4AYGPdR1PUiW4WwZOstEtnxsmvBBcfzhy/qXb5aS nc2TYiubaWdly3EnJPtBTO9YM6efuXMqVzyVhcbWr8Qp8BuOf4w3fHd0skHpXkFLQSLC ik59Rk8Nx6EGEr1wa3/zxtl54quOiLhqQdzQRxa899q9sLcaWyLXtefHVhPfY3uG+eaG H2yywEUZVbbRzkyin8lXD4VI+oyhnaLv3atDpoAmBr15LfdAqmictcQD9UXrmF6ypqZ5 qsZQ== 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=mJ07ciWiBLzJ+zvyi87SFzZlLJ47JWnJIRmtDCBPdJ4=; b=iYwPcb69i0OTVnO3QD0ZNayRC33oNB3Br9gqzok9mT3afm+jQnRsS4F+UXZrujDpNQ 3Ldk7am+OSLea1GOBJvCMm0N6gSboVaybB+HwWp7+EtCjskQtBdy83oJBdLfud2p/hTl jfR97BTG0GcgqjE/cyYIgk6GlACYbG2QF1/1VagKj7NyN5aI0gA3ag2nBcwXjE+UqqG+ aG/i7wFfIzHvj6qHhheourvjBZi4VYAlOogjKXvm2N/kveS9HbE2Y8Zjsq4vgxxPz/lM F5VFGild4sJGbYlh16WQT8vRkZajNyjnPe1V2CB6U1lSU1fYqX6B96uCvMwZ5+ibAlnk RkHQ== X-Received: by 10.68.28.232 with SMTP id e8mr21960151pbh.94.1373295413133; Mon, 08 Jul 2013 07:56:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 07:56:13 -0700 (PDT) In-Reply-To: References: <8B58E2AB-09B7-4816-8BC4-B932030E2ED2@iii.ca> <51DAD083.8000901@stpeter.im> From: Peter Thatcher Date: Mon, 8 Jul 2013 07:56:13 -0700 Message-ID: To: Philipp Hancke Content-Type: multipart/alternative; boundary=bcaec520eacd45a49a04e101410c X-Gm-Message-State: ALoCoQk4lKZQ0NUQxKomNZPYhVXUFp39gpYrEBIJujJH+80mgaoTq7DKQ+3UgOauX8DWxcBUCIiUcE51OPr81xo7u7F4MlOjM+ToPrcBTxbL9X9MMueGhvTJ47F3yUjrALI11KnFeTadRk5fcRzjXoaRbN7jus7+cBJ8mySLKWQLSZv3kJZnLMPIuw2UhpajzClXCWRd68mO Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:56:58 -0000 --bcaec520eacd45a49a04e101410c Content-Type: text/plain; charset=UTF-8 I'm fine with "mangle". On Mon, Jul 8, 2013 at 7:54 AM, Philipp Hancke wrote: > On Mon, 8 Jul 2013, Peter Thatcher wrote: > >> > > So compatibility with SIP is important but compatibility with >> > Jingle is just impossible. >> > >> > The mapping of SDP to jingle is in the Jingle specs ? I'm not >> > express any opinion on this one way or another other but the authors >> > of theses specs have always claimed Jingle fully mapped to and from >> SDP. >> > >> > >> > I think he meant "impossible without SDP munging", which I think is >> > undeniable. >> >> What do you mean by "SDP munging"? >> >> >> I mean that if the JS wants to send Jingle XML over the wire, it has to >> parse the SDP. Then, when it receives Jingle XML, it has to serialize SDP. >> That parsing and serializing of SDP I call "munging". We could come up >> with better words for more specific >> activities, but that seems to be the word everyone else uses, so it's >> what I've used. >> > > I think "mangle" is a better term here. People who want to do jingle are > aware of the fact that this is more difficult than running their own > proprietary stuff over xml. Or use SoX :-) --bcaec520eacd45a49a04e101410c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm fine with "mangle".=C2=A0


On Mon, Jul 8, 2013 at= 7:54 AM, Philipp Hancke <fippo@goodadvice.pages.de>= wrote:
On Mon, 8 Jul 2013, Peter = Thatcher wrote:
> =C2=A0 =C2=A0 > So compatibility with SIP is important but compatib= ility with
> =C2=A0 =C2=A0 Jingle is just impossible.
>
> =C2=A0 =C2=A0 The mapping of SDP to jingle is in the Jingle specs ? I&= #39;m not
> =C2=A0 =C2=A0 express any opinion on this one way or another other but= the authors
> =C2=A0 =C2=A0 of theses specs have always claimed Jingle fully mapped = to and from SDP.
>
>
> I think he meant "impossible without SDP munging", which I t= hink is
> undeniable.

What do you mean by "SDP munging"?


I mean that if the JS wants to send Jingle XML over the wire, it has to par= se the SDP. =C2=A0Then, when it receives Jingle XML, it has to serialize SD= P. =C2=A0 That parsing and serializing of SDP I call "munging". = =C2=A0We could come up with better words for more specific
activities, but that seems to be the word everyone else uses, so it's w= hat I've used.

I think "mangle" is a better term here. People who want to do jin= gle are aware of the fact that this is more difficult than running their ow= n proprietary stuff over xml. Or use SoX :-)

--bcaec520eacd45a49a04e101410c-- From pthatcher@google.com Mon Jul 8 08:01:22 2013 Return-Path: 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 D343D21F9D58 for ; Mon, 8 Jul 2013 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_URI_CONS7=0.306] 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 sd6teSC3+oN0 for ; Mon, 8 Jul 2013 08:01:22 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4774C21F9C7C for ; Mon, 8 Jul 2013 08:01:22 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id q10so4195687pdj.10 for ; Mon, 08 Jul 2013 08:01:22 -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=FvkQSM7UBeamAvyABVAnUrM1Pvjckq5i8vl3I77KcSk=; b=OQxE8UVeaJeZniUSZR8/NT2oIMO1NaYYMR4Lv51h5r7XS7MN4yEAk6M1ieoks7Mu4B qeswz0S67Fivp7HatfkRHbCW5pbJAfvhh0fNHI9ZUa1C3YwMTBeW7DyDToBzm2hdg1ga mCYBay3+aMU2fDqarzQeATGV+wsMLD0v9p7ZN29dGOwNzN5xPDWKRLNE6ZOrg0k7xfHX zE8JY3hwfT5hh5WCHUN5S0ywp5dEScVYPqTeJal1O0sr0spmbgqzE2/Ts09S2/S86A22 pEyom50V1pAS1+DTCCyRabLNz7Fbg4uTQoH94bInY31ISbD+5kV3SWq8d1l+5gFkIImB wb5A== 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=FvkQSM7UBeamAvyABVAnUrM1Pvjckq5i8vl3I77KcSk=; b=Pa9qFhX0XasmQrxG36JnvRDoiUcjFvnaSPuJpu0Q49/VKQkQwgMgFR7iBjFhzd0XYh e0zcErM2Vj+8YCMMjTE07auik8rl0Sy1FxxPM5zmJHHrp9sY2ljRzKI1wWiOQ0vNDGnM ib9eOYSF/LXv1GrE4kIeYoBm1ePNGT2MY0ZNAEkgheNk5GOlqOSd1csp46zbNp5Sdimm 67SLJPD/RDDJqsO6PCg8KCHZ39fBtfEKw32rhhFOFhXhNtcweZMf3jZL1ry74EreC5C+ HLJFN3bC0E8nPgeDF1OzVFFQwQ6VjwQor+nNeg+0WpZiewu7KMghINHhUhbib3rRTHTF r+Qw== X-Received: by 10.68.29.2 with SMTP id f2mr21780269pbh.184.1373295681925; Mon, 08 Jul 2013 08:01:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 08:00:41 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> From: Peter Thatcher Date: Mon, 8 Jul 2013 08:00:41 -0700 Message-ID: To: Silvia Pfeiffer Content-Type: multipart/alternative; boundary=bcaec520f3b94b220204e1015139 X-Gm-Message-State: ALoCoQlrTfipUdfPwmnMSDGJ2BD09zorQgEZ+22XgwpGCd7scYKXXGNwIsv6IWF+3qMsHfkL5vvdwDgv2t/HfrpcGfVhphbC/mAqm8Le0eouCYMkduE3AuQz0iL/Mhm0LV+HQmWahT1bGJBwRXrEibJBvIA7BaWlGWQJ+jE+S3FBSAhDYvtL9yyxEQmwAHgT47ONia+yXsXr Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:01:22 -0000 --bcaec520f3b94b220204e1015139 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 6, 2013 at 3:59 AM, Silvia Pfeiffer wrote: > An interesting read. It makes me wonder if there is a full description > available of the SDP that browsers (Chrome, Firefox) currently > support. > Here's the description for Chrome: https://code.google.com/p/libjingle/source/browse/trunk/talk/app/webrtc/webrtcsdp.cc :) > > Looking forward to your proposal (I assume it will be on the W3C list?). > > Cheers, > Silvia. > > On Wed, Jun 26, 2013 at 2:37 PM, Robin Raymond > wrote: > > > > According to many, real adoption of WebRTC will not happen if we > continue to > > force everyone to use this SDP Offer/Answer methodology. It is clearly > > blocking our way forward and the amount of specification documentation > > remaining needed for the browser vendors to produce a compatible SDP > based > > WebRTC engine in a browser is much more daunting than most are willing to > > admit. > > > > > > The draft rationale behind a JavaScript Object API model: > > > > > http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt > > > > Whereas: > > > > The WebRTC JavaScript Object API & Shim document will be along shortly. > > > > > > We wanted to get this initial rationale draft informational document out > > right away. Everyone that has any interest should review the reasons and > > concepts and comment before we get too far along on the details of an > actual > > API, the initial API will follow in the coming days. > > > > > > Best regards, > > > > Robin Raymond > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec520f3b94b220204e1015139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Jul 6, 2013 at 3:59 AM, Silvia Pfeiffer &= lt;silviapfe= iffer1@gmail.com> wrote:
An interesting read. It makes me wonder if there is a full= description
available of the SDP that browsers (Chrome, Firefox) currently
support.

Here's the description for= Chrome:


:)
=C2=A0

Looking forward to your proposal (I assume it will be on the W3C list?).
Cheers,
Silvia.

On Wed, Jun 26, 2013 at 2:37 PM, Robin Raymond <robin@hookflash.com> wrote:
>
> According to many, real adoption of WebRTC will not happen if we conti= nue to
> force everyone to use this SDP Offer/Answer methodology. =C2=A0It is c= learly
> blocking our way forward and the amount of specification documentation=
> remaining needed for the browser vendors to produce a compatible SDP b= ased
> WebRTC engine in a browser is much more daunting than most are willing= to
> admit.
>
>
> The draft rationale behind a JavaScript Object API model:
>
> http://www.ietf.org/int= ernet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt >
> Whereas:
>
> The WebRTC JavaScript Object API & Shim document will be along sho= rtly.
>
>
> We wanted to get this initial rationale draft informational document o= ut
> right away. Everyone that has any interest should review the reasons a= nd
> concepts and comment before we get too far along on the details of an = actual
> API, the initial API will follow in the coming days.
>
>
> Best regards,
>
> Robin Raymond
>
>
> ________________________= _______________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec520f3b94b220204e1015139-- From jim.barnett@genesyslab.com Mon Jul 8 08:02:39 2013 Return-Path: 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 EADD221F9D6B for ; Mon, 8 Jul 2013 08:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 kw9h-LKYlGG9 for ; Mon, 8 Jul 2013 08:02:33 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE3321F9D68 for ; Mon, 8 Jul 2013 08:02:33 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Mon, 08 Jul 2013 11:02:27 -0400 Received: from GENSJZMBX01.msg.int.genesyslab.com ([fe80::c80a:d985:3cca:a5e7]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 08:02:25 -0700 From: Jim Barnett To: Peter Thatcher , Philipp Hancke Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOe+kjuVJVaRVSxkOhmsGbhpzWAplbUROAgAAAuoCAAAGzAIAAAJqA//+LoGA= Date: Mon, 8 Jul 2013 15:02:24 +0000 Message-ID: <57A15FAF9E58F841B2B1651FFE16D281057B7A@GENSJZMBX01.msg.int.genesyslab.com> References: <8B58E2AB-09B7-4816-8BC4-B932030E2ED2@iii.ca> <51DAD083.8000901@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.7.220.231] MIME-Version: 1.0 X-MC-Unique: 113070811022800302 Content-Type: multipart/alternative; boundary="_000_57A15FAF9E58F841B2B1651FFE16D281057B7AGENSJZMBX01msgint_" Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:02:40 -0000 --_000_57A15FAF9E58F841B2B1651FFE16D281057B7AGENSJZMBX01msgint_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IHdlIG5lZWQgYSBzZXBhcmF0ZSB2ZXJiIHRvIGRlc2NyaWJlIHRoZSBjYXNl IHdoZXJlIHRoZSBkZXZlbG9wZXIgbmVlZHMgdG8gbW9kaWZ5IHRoZSBTRFAgaXRzZWxmIChpLmUu LCByYXRoZXIgdGhhbiB0cmFuc2xhdGlvbiBpdCBpbnRvIG9yIG91dCBvZiBhbm90aGVyIGxhbmd1 YWdlKS4gIFRob3NlIGFyZSBkaWZmZXJlbnQgdXNlIGNhc2VzLCBhbmQgZGlmZmVyZW50IHNvcnRz IG9mIHByb2JsZW1zLg0KDQoNCi0gICAgICAgICAgSmltDQoNCkZyb206IHJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQ ZXRlciBUaGF0Y2hlcg0KU2VudDogTW9uZGF5LCBKdWx5IDA4LCAyMDEzIDEwOjU2IEFNDQpUbzog UGhpbGlwcCBIYW5ja2UNCkNjOiA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3 ZWJdIFN1bW1hcnkgb2YgQXBwbGljYXRpb24gRGV2ZWxvcGVycycgb3BpbmlvbnMgb2YgdGhlIGN1 cnJlbnQgV2ViUlRDIEFQSSBhbmQgU0RQIGFzIGEgY29udHJvbCBzdXJmYWNlDQoNCkknbSBmaW5l IHdpdGggIm1hbmdsZSIuDQoNCk9uIE1vbiwgSnVsIDgsIDIwMTMgYXQgNzo1NCBBTSwgUGhpbGlw cCBIYW5ja2UgPGZpcHBvQGdvb2RhZHZpY2UucGFnZXMuZGU8bWFpbHRvOmZpcHBvQGdvb2RhZHZp Y2UucGFnZXMuZGU+PiB3cm90ZToNCk9uIE1vbiwgOCBKdWwgMjAxMywgUGV0ZXIgVGhhdGNoZXIg d3JvdGU6DQo+ICAgICA+IFNvIGNvbXBhdGliaWxpdHkgd2l0aCBTSVAgaXMgaW1wb3J0YW50IGJ1 dCBjb21wYXRpYmlsaXR5IHdpdGgNCj4gICAgIEppbmdsZSBpcyBqdXN0IGltcG9zc2libGUuDQo+ DQo+ICAgICBUaGUgbWFwcGluZyBvZiBTRFAgdG8gamluZ2xlIGlzIGluIHRoZSBKaW5nbGUgc3Bl Y3MgPyBJJ20gbm90DQo+ICAgICBleHByZXNzIGFueSBvcGluaW9uIG9uIHRoaXMgb25lIHdheSBv ciBhbm90aGVyIG90aGVyIGJ1dCB0aGUgYXV0aG9ycw0KPiAgICAgb2YgdGhlc2VzIHNwZWNzIGhh dmUgYWx3YXlzIGNsYWltZWQgSmluZ2xlIGZ1bGx5IG1hcHBlZCB0byBhbmQgZnJvbSBTRFAuDQo+ DQo+DQo+IEkgdGhpbmsgaGUgbWVhbnQgImltcG9zc2libGUgd2l0aG91dCBTRFAgbXVuZ2luZyIs IHdoaWNoIEkgdGhpbmsgaXMNCj4gdW5kZW5pYWJsZS4NCg0KV2hhdCBkbyB5b3UgbWVhbiBieSAi U0RQIG11bmdpbmciPw0KDQoNCkkgbWVhbiB0aGF0IGlmIHRoZSBKUyB3YW50cyB0byBzZW5kIEpp bmdsZSBYTUwgb3ZlciB0aGUgd2lyZSwgaXQgaGFzIHRvIHBhcnNlIHRoZSBTRFAuICBUaGVuLCB3 aGVuIGl0IHJlY2VpdmVzIEppbmdsZSBYTUwsIGl0IGhhcyB0byBzZXJpYWxpemUgU0RQLiAgIFRo YXQgcGFyc2luZyBhbmQgc2VyaWFsaXppbmcgb2YgU0RQIEkgY2FsbCAibXVuZ2luZyIuICBXZSBj b3VsZCBjb21lIHVwIHdpdGggYmV0dGVyIHdvcmRzIGZvciBtb3JlIHNwZWNpZmljDQphY3Rpdml0 aWVzLCBidXQgdGhhdCBzZWVtcyB0byBiZSB0aGUgd29yZCBldmVyeW9uZSBlbHNlIHVzZXMsIHNv IGl0J3Mgd2hhdCBJJ3ZlIHVzZWQuDQoNCkkgdGhpbmsgIm1hbmdsZSIgaXMgYSBiZXR0ZXIgdGVy bSBoZXJlLiBQZW9wbGUgd2hvIHdhbnQgdG8gZG8gamluZ2xlIGFyZSBhd2FyZSBvZiB0aGUgZmFj dCB0aGF0IHRoaXMgaXMgbW9yZSBkaWZmaWN1bHQgdGhhbiBydW5uaW5nIHRoZWlyIG93biBwcm9w cmlldGFyeSBzdHVmZiBvdmVyIHhtbC4gT3IgdXNlIFNvWCA6LSkNCg0K --_000_57A15FAF9E58F841B2B1651FFE16D281057B7AGENSJZMBX01msgint_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTcxMTQxNjMy NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExNDY0 MjQ3NTAgNDgxNDM4MzQ4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Ik1TIE1pbmNo byI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoYXQgd2UgbmVlZCBhIHNlcGFyYXRl IHZlcmIgdG8gZGVzY3JpYmUgdGhlIGNhc2Ugd2hlcmUgdGhlIGRldmVsb3BlciBuZWVkcyB0byBt b2RpZnkgdGhlIFNEUCBpdHNlbGYgKGkuZS4sIHJhdGhlciB0aGFuIHRyYW5zbGF0aW9uIGl0IGlu dG8gb3Igb3V0IG9mDQogYW5vdGhlciBsYW5ndWFnZSkuJm5ic3A7IFRob3NlIGFyZSBkaWZmZXJl bnQgdXNlIGNhc2VzLCBhbmQgZGlmZmVyZW50IHNvcnRzIG9mIHByb2JsZW1zLiAmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SmltPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QZXRl ciBUaGF0Y2hlcjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMDgsIDIwMTMgMTA6NTYg QU08YnI+DQo8Yj5Ubzo8L2I+IFBoaWxpcHAgSGFuY2tlPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7cnRj d2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gU3VtbWFy eSBvZiBBcHBsaWNhdGlvbiBEZXZlbG9wZXJzJyBvcGluaW9ucyBvZiB0aGUgY3VycmVudCBXZWJS VEMgQVBJIGFuZCBTRFAgYXMgYSBjb250cm9sIHN1cmZhY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBmaW5lIHdpdGggJnF1b3Q7bWFuZ2xlJnF1b3Q7 LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1bCA4LCAyMDEzIGF0IDc6NTQgQU0s IFBoaWxpcHAgSGFuY2tlICZsdDs8YSBocmVmPSJtYWlsdG86ZmlwcG9AZ29vZGFkdmljZS5wYWdl cy5kZSIgdGFyZ2V0PSJfYmxhbmsiPmZpcHBvQGdvb2RhZHZpY2UucGFnZXMuZGU8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24s IDggSnVsIDIwMTMsIFBldGVyIFRoYXRjaGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZndDsgU28gY29tcGF0aWJpbGl0eSB3 aXRoIFNJUCBpcyBpbXBvcnRhbnQgYnV0IGNvbXBhdGliaWxpdHkgd2l0aDxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyBKaW5nbGUgaXMganVzdCBpbXBvc3NpYmxlLjxicj4NCiZndDs8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgVGhlIG1hcHBpbmcgb2YgU0RQIHRvIGppbmdsZSBpcyBpbiB0aGUgSmlu Z2xlIHNwZWNzID8gSSdtIG5vdDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBleHByZXNzIGFueSBv cGluaW9uIG9uIHRoaXMgb25lIHdheSBvciBhbm90aGVyIG90aGVyIGJ1dCB0aGUgYXV0aG9yczxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyBvZiB0aGVzZXMgc3BlY3MgaGF2ZSBhbHdheXMgY2xhaW1l ZCBKaW5nbGUgZnVsbHkgbWFwcGVkIHRvIGFuZCBmcm9tIFNEUC48YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgSSB0aGluayBoZSBtZWFudCAmcXVvdDtpbXBvc3NpYmxlIHdpdGhvdXQgU0RQ IG11bmdpbmcmcXVvdDssIHdoaWNoIEkgdGhpbmsgaXM8YnI+DQomZ3Q7IHVuZGVuaWFibGUuPGJy Pg0KPGJyPg0KV2hhdCBkbyB5b3UgbWVhbiBieSAmcXVvdDtTRFAgbXVuZ2luZyZxdW90Oz88YnI+ DQo8YnI+DQo8YnI+DQpJIG1lYW4gdGhhdCBpZiB0aGUgSlMgd2FudHMgdG8gc2VuZCBKaW5nbGUg WE1MIG92ZXIgdGhlIHdpcmUsIGl0IGhhcyB0byBwYXJzZSB0aGUgU0RQLiAmbmJzcDtUaGVuLCB3 aGVuIGl0IHJlY2VpdmVzIEppbmdsZSBYTUwsIGl0IGhhcyB0byBzZXJpYWxpemUgU0RQLiAmbmJz cDsgVGhhdCBwYXJzaW5nIGFuZCBzZXJpYWxpemluZyBvZiBTRFAgSSBjYWxsICZxdW90O211bmdp bmcmcXVvdDsuICZuYnNwO1dlIGNvdWxkIGNvbWUgdXAgd2l0aCBiZXR0ZXIgd29yZHMgZm9yIG1v cmUgc3BlY2lmaWM8YnI+DQphY3Rpdml0aWVzLCBidXQgdGhhdCBzZWVtcyB0byBiZSB0aGUgd29y ZCBldmVyeW9uZSBlbHNlIHVzZXMsIHNvIGl0J3Mgd2hhdCBJJ3ZlIHVzZWQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayAmcXVvdDttYW5nbGUmcXVvdDsgaXMgYSBiZXR0 ZXIgdGVybSBoZXJlLiBQZW9wbGUgd2hvIHdhbnQgdG8gZG8gamluZ2xlIGFyZSBhd2FyZSBvZiB0 aGUgZmFjdCB0aGF0IHRoaXMgaXMgbW9yZSBkaWZmaWN1bHQgdGhhbiBydW5uaW5nIHRoZWlyIG93 biBwcm9wcmlldGFyeSBzdHVmZiBvdmVyIHhtbC4gT3IgdXNlIFNvWCA6LSk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_57A15FAF9E58F841B2B1651FFE16D281057B7AGENSJZMBX01msgint_-- From roman@telurix.com Mon Jul 8 08:22:53 2013 Return-Path: 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 5F4D821F9C22 for ; Mon, 8 Jul 2013 08:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 zud7WCRKGIYf for ; Mon, 8 Jul 2013 08:22:48 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81A21F9A30 for ; Mon, 8 Jul 2013 08:22:43 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so3763293wgh.26 for ; Mon, 08 Jul 2013 08:22:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=svhGGqmStcxWq+HMnOu08iueCYlYJKqc3t1JDhQX9Yw=; b=S42HA78s2+pDC6MfLNKx9aZlhKrpObGmoJ+APA9KDSLZkAnxzszQqQLqiHo0WFQPX4 POk5I/yqlSCdZ4GgOnRJ/w+JJjL0cN/U0yiQsCbtsht7ql++jR8kqQfheqt6uwtfRUZl jbWUv094Mx2oxFrwps4idFifAKb5CORsKOERDGXAG0WRxl8avoXc4X1PGHapbkpK5P8v KRwQvFsqsucvfF8+Lqy0twcZX8EmHqiQ71UKIgzW2TnYQiliYZOZqdzPkdOX3UV87bIC zCYP4yQF2Tab30sqCJqFlp5ezwC8s78heDE5A1cy92j9HK8TrJVBs5hPUwFqNqqCJoJW xbiA== X-Received: by 10.180.211.7 with SMTP id my7mr29626870wic.26.1373296960508; Mon, 08 Jul 2013 08:22:40 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [2a00:1450:400c:c05::22c]) by mx.google.com with ESMTPSA id m6sm22169994wiy.8.2013.07.08.08.22.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 08:22:39 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so9160107wiw.5 for ; Mon, 08 Jul 2013 08:22:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.9.212 with SMTP id c20mr29380375wib.65.1373296958260; Mon, 08 Jul 2013 08:22:38 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Mon, 8 Jul 2013 08:22:38 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> Date: Mon, 8 Jul 2013 11:22:38 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= Content-Type: multipart/alternative; boundary=001a11c1879c5e4e6c04e1019da9 X-Gm-Message-State: ALoCoQmraL81y5fuL/tICfDkeile7TJ0LrriCnjWd/wC6ZVRRWk2kygVPjSSA+ZpJyEE1KeK4mqq Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:22:54 -0000 --001a11c1879c5e4e6c04e1019da9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 8, 2013 at 8:11 AM, Stefan H=E5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > > On Sat, Jul 6, 2013 at 2:33 AM, Stefan H=E5kansson LK > > > > wrote: > > > > On 7/3/13 11:37 PM, Eric Rescorla wrote: > > > I'm glad to be wrong here. Is the phrase "you shouldn't hav= e > to > > > modify the SDP but rather there should be API points to cove= r > > most > > > of the use cases" the consensus of the working group? > > > > > > > > > I thought it was, but I'm not the chair, so maybe you could ask > > Harald or > > > Stefan. > > > > I definitely think this is the consensus of the working group. > > > > > > Can you point out when exactly this consensus was reached? This is news > > to me, but I definitely could have missed something. > > No I can't really. To be clear, no consensus call (or similar) has been > held. But every time this is discussed, what I hear is people agreeing > and no objections. It was discussed a bit, e.g., at the f2f at TPAC last > year, if you read the minutes [1] you will find some traces of that > discussion. > > And, I don't understand why there would be a debate about this. There > are obviously many who want to define APIs (or constraints) that allow > most use-cases to be met without having to modify the SDP. Why would > anyone have anything against that? If there is anyone who really wants > to modify the SDP instead (I have no clue why, but anyway) they can > still do that. > > [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Nov/0072.html > > I would not disagree that there should not be any debate that things that can be done through API should be done through API. My question is, was there ever consensus that SDP should be a opaque non modifiable blob which should not be used within the application to control things. Or is SDP just a more advanced API surface that is supposed to be used to implement more advanced scenarios? Is this group even suppose to specify what can be modified in by the application SDP or is it supposed to be an empty set? So, was there ever a consensus that "developers MUST NOT touch SDP"? _____________ Roman Shpount --001a11c1879c5e4e6c04e1019da9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 8, 2013 at 8:11 AM, Stefan H=E5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
> On Sat, Jul 6, 2013 a= t 2:33 AM, Stefan H=E5kansson LK
> <stefan.lk.haka= nsson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
> =A0 =A0 On 7/3/13 11:37 PM, Eric Rescorla wrote:
> =A0 =A0 =A0> =A0 =A0 I'm glad to be wrong here. =A0Is the phras= e "you shouldn't have to
> =A0 =A0 =A0> =A0 =A0 modify the SDP but rather there should be API = points to cover
> =A0 =A0 most
> =A0 =A0 =A0> =A0 =A0 of the use cases" =A0the consensus of the= working group?
> =A0 =A0 =A0>
> =A0 =A0 =A0>
> =A0 =A0 =A0> I thought it was, but I'm not the chair, so maybe = you could ask
> =A0 =A0 Harald or
> =A0 =A0 =A0> Stefan.
>
> =A0 =A0 I definitely think this is the consensus of the working group.=
>
>
> Can you point out when exactly this consensus was reached? This is new= s
> to me, but I definitely could have missed something.

No I can't really. To be clear, no consensus call (or similar) ha= s been
held. But every time this is discussed, what I hear is people agreeing
and no objections. It was discussed a bit, e.g., at the f2f at TPAC last year, if you read the minutes [1] you will find some traces of that
discussion.

And, I don't understand why there would be a debate about this. There are obviously many who want to define APIs (or constraints) that allow
most use-cases to be met without having to modify the SDP. Why would
anyone have anything against that? If there is anyone who really wants
to modify the SDP instead (I have no clue why, but anyway) they can
still do that.

[1] http://lists.w3.org/Archives/Public/public-webrt= c/2012Nov/0072.html


I would not disagree that there should= not be any debate that things that can be done through API should be done = through API. My question is, was there ever consensus that SDP should be a = opaque non modifiable blob which should not be used within the application = to control things. Or is SDP just a more advanced API surface that is suppo= sed to be used to implement more advanced scenarios? Is this group even sup= pose to specify what can be modified in by the application SDP or is it sup= posed to be an empty set? So, was there ever a consensus that "develop= ers MUST NOT touch SDP"?

_____________
Roman Shpount
=A0
--001a11c1879c5e4e6c04e1019da9-- From pthatcher@google.com Mon Jul 8 08:26:56 2013 Return-Path: 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 E27AF21F9B85 for ; Mon, 8 Jul 2013 08:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, 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 dO5sLkG7qopy for ; Mon, 8 Jul 2013 08:26:56 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D745521F9A57 for ; Mon, 8 Jul 2013 08:26:55 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md12so4421877pbc.16 for ; Mon, 08 Jul 2013 08:26:55 -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=zX28nLztmPdH90/0P4G7bUdmoeb7kqRCK4Mbguenc+Y=; b=jOvBvkawdiWHhvXKwVNXyP9iG17CZ52HYUJ/9ZiPSApUvIAZk5muEh+tvpmFI1awMP uuXhurhq1SPS4vq7OEdhLll6dVgt1aNUAvuGO5aJ2j94r0/6gNMTYwHzVc6VYAkNiDrc xH56swGvkSRULK1WDeEhXfAc6FbzL+AuJwk/BdA+Ogj3UrQ5A8XRIkZLHI8uzumjSoSn QO5IzX5cU2abTy7ezacnrhB7X0m1VsPL+7zrU9g/FhoPuPLGs4PrLtVLCr8RkF+bC5HL yPaDJnVwwrWkdSuqjCg2rts3VqLGia/1TU7CM7mWjJB8qP4CzCNBBS5Bw9jKpyR3WNRk D/bA== 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=zX28nLztmPdH90/0P4G7bUdmoeb7kqRCK4Mbguenc+Y=; b=erXw59180Me3HavxPWe1r4ypoKoB97zW20bmnxHqabdI6hVXEnD+mLpyWILhTpq9OJ Eai505IDPF2snZNqGM71hfIfxhtltvEchykZGLCCV+pEas2R/DjknTLqlRgT5IdcpX54 Y5fGEv+w9tNhDvvgYfVi2Xno6HW2kHObpoXI1vt/QnIk6cxxMtR4hKnAtyT4byrqGFeu KoKrr7B/Kevv0eraMRooUPRnYVxMaCjJPTFMGAlse24Q7xd7gQ9DCXRjEovyFYFOYrvZ FaA0QrmfKufQCduxe+/2YQr3C5tzRp6ZLoA6AdvVfiozpYzu/v/F4P55ckkiHy5kasKV gc6Q== X-Received: by 10.66.14.196 with SMTP id r4mr23751242pac.57.1373297215409; Mon, 08 Jul 2013 08:26:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 08:26:15 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Mon, 8 Jul 2013 08:26:15 -0700 Message-ID: To: Philipp Hancke Content-Type: multipart/alternative; boundary=bcaec51f99e5b2318704e101ac8d X-Gm-Message-State: ALoCoQn78Jy+sVSA7XvZLxBFnNR2rFTHc8ckvVansxeAmU2jo3T4TXbe+g0sxYZzgKQsOe+jtGBjBQZwKgB08izz1s44zMyMKDuJHVjUjCSFIS0lyF/Wj+EG/msTgbmJ0A9px/9mtjMgpsjDrZBgr8k3gkeMamyK6sigtgPieLoooIRdn+e9a2iZXp9fBLlYsRPrl1SNbi3z Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:26:57 -0000 --bcaec51f99e5b2318704e101ac8d Content-Type: text/plain; charset=UTF-8 Whoops, nevermind. It's been there since http://tools.ietf.org/html/draft-uberti-rtcweb-jsep-00, and it's not what I thought it was at first glance. So forget what I said :). On Mon, Jul 8, 2013 at 7:54 AM, Peter Thatcher wrote: > > > > On Wed, Jul 3, 2013 at 11:35 PM, Philipp Hancke > wrote: > >> On Wed, 3 Jul 2013, Eric Rescorla wrote: >> >>> Who said anything about impossible? It's a mechanical transformation >>> (see: http://xmpp.org/**extensions/xep-0167.html >>> ). >>> >> >> That is true for simple usage and works reasonably well. See my >> strophe.jingle code on github. I'd note that I want to revamp >> the API such that it wraps the peerconnections SDP apis more closely. >> >> Things like the content-add/content-remove are harder because the API >> user is required to calculate an SDP delta/diff. The appendix A.1.3 of the >> JSEP draft calls this createContentAdd, parseContentAdd, >> createContentAccept and parseContentAccept. Has anyone ever implemented >> those operations in javascript and can demonstrate running code? >> > > I think those were added about a week ago. Both Chrome and Firefox try to > update quickly, but that would be amazing! > > >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --bcaec51f99e5b2318704e101ac8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Whoops, nevermind. =C2=A0It's been there since=C2=A0http://too= ls.ietf.org/html/draft-uberti-rtcweb-jsep-00, and it's not what I t= hought it was at first glance. =C2=A0So forget what I said :).


On Mon, Jul 8= , 2013 at 7:54 AM, Peter Thatcher <pthatcher@google.com> = wrote:



On Wed, Jul 3= , 2013 at 11:35 PM, Philipp Hancke <fippo@goodadvice.pages.de&= gt; wrote:
On Wed, 3 Jul 2013, Eric Rescorla wrote= :
Who said anything about impossible? It's a mechanical transformation (see:=C2=A0http://xmpp.org/extensions/xep-0167.html).

That is true for simple usage and works reasonably well. See my
strophe.jingle code on github. I'd note that I want to revamp
the API such that it wraps the peerconnections SDP apis more closely.

Things like the content-add/content-remove are harder because the API user = is required to calculate an SDP delta/diff. The appendix A.1.3 of the JSEP = draft calls this createContentAdd, parseContentAdd, createContentAccept and= parseContentAccept. Has anyone ever implemented those operations in javasc= ript and can demonstrate running code?

I think those were added about= a week ago. =C2=A0Both Chrome and Firefox try to update quickly, but that = would be amazing!
=C2=A0
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb



--bcaec51f99e5b2318704e101ac8d-- From jim.barnett@genesyslab.com Mon Jul 8 08:30:09 2013 Return-Path: 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 094C921F9473 for ; Mon, 8 Jul 2013 08:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 wfo5-PD8MC0o for ; Mon, 8 Jul 2013 08:29:58 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1281621F9C22 for ; Mon, 8 Jul 2013 08:29:57 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service108-us.mimecast.com; Mon, 08 Jul 2013 11:29:56 -0400 Received: from GENSJZMBX01.msg.int.genesyslab.com ([fe80::c80a:d985:3cca:a5e7]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 08:29:55 -0700 From: Jim Barnett To: Roman Shpount , =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOeDFb4WMYLBZuekGl1k39EmxfOJlbYusA//+MFuA= Date: Mon, 8 Jul 2013 15:29:55 +0000 Message-ID: <57A15FAF9E58F841B2B1651FFE16D281057BD4@GENSJZMBX01.msg.int.genesyslab.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.7.220.231] MIME-Version: 1.0 X-MC-Unique: 113070811295601502 Content-Type: multipart/alternative; boundary="_000_57A15FAF9E58F841B2B1651FFE16D281057BD4GENSJZMBX01msgint_" Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:30:09 -0000 --_000_57A15FAF9E58F841B2B1651FFE16D281057BD4GENSJZMBX01msgint_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable As I recall the consensus, developers are supposed to be able to modify the= SDP, but we needed to specify what parts of the SDP could be modified. In= other words, there might be some limits to what could be modified, but we = haven't yet determined/agreed on what they are. - Jim From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Roman Shpount Sent: Monday, July 08, 2013 11:23 AM To: Stefan H=E5kansson LK Cc: Subject: Re: [rtcweb] Summary of Application Developers' opinions of the cu= rrent WebRTC API and SDP as a control surface On Mon, Jul 8, 2013 at 8:11 AM, Stefan H=E5kansson LK > wrote: > On Sat, Jul 6, 2013 at 2:33 AM, Stefan H=E5kansson LK > > >> wrote: > > On 7/3/13 11:37 PM, Eric Rescorla wrote: > > I'm glad to be wrong here. Is the phrase "you shouldn't have = to > > modify the SDP but rather there should be API points to cover > most > > of the use cases" the consensus of the working group? > > > > > > I thought it was, but I'm not the chair, so maybe you could ask > Harald or > > Stefan. > > I definitely think this is the consensus of the working group. > > > Can you point out when exactly this consensus was reached? This is news > to me, but I definitely could have missed something. No I can't really. To be clear, no consensus call (or similar) has been held. But every time this is discussed, what I hear is people agreeing and no objections. It was discussed a bit, e.g., at the f2f at TPAC last year, if you read the minutes [1] you will find some traces of that discussion. And, I don't understand why there would be a debate about this. There are obviously many who want to define APIs (or constraints) that allow most use-cases to be met without having to modify the SDP. Why would anyone have anything against that? If there is anyone who really wants to modify the SDP instead (I have no clue why, but anyway) they can still do that. [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Nov/0072.html I would not disagree that there should not be any debate that things that c= an be done through API should be done through API. My question is, was ther= e ever consensus that SDP should be a opaque non modifiable blob which shou= ld not be used within the application to control things. Or is SDP just a m= ore advanced API surface that is supposed to be used to implement more adva= nced scenarios? Is this group even suppose to specify what can be modified = in by the application SDP or is it supposed to be an empty set? So, was the= re ever a consensus that "developers MUST NOT touch SDP"? _____________ Roman Shpount --_000_57A15FAF9E58F841B2B1651FFE16D281057BD4GENSJZMBX01msgint_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

As I recall the consensus= , developers are supposed to be able to modify the SDP, but we needed to sp= ecify what parts of the SDP could be modified.  In other words, there might be some limits to what could be modified, but we haven&= #8217;t yet determined/agreed on what they are.

 <= /p>

- =          Jim

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: Monday, July 08, 2013 11:23 AM
To: Stefan H=E5kansson LK
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] Summary of Application Developers' opinions of= the current WebRTC API and SDP as a control surface

 

On Mon, Jul 8, 2013 at 8:11 AM, Stefan H=E5kansson L= K <stefan.lk.hakansson@ericsson.com> wrote:

> On Sat, Jul 6, 2013 at 2:33 AM, Stefan H=E5kans= son LK
> <stefan.lk.haka= nsson@ericsson.com

> <mailto:stefan.lk.hakansson@ericsson= .com>> wrote:
>
>     On 7/3/13 11:37 PM, Eric Rescorla wrote:
>      >     I'm glad to be wrong here. &nbs= p;Is the phrase "you shouldn't have to
>      >     modify the SDP but rather there= should be API points to cover
>     most
>      >     of the use cases"  th= e consensus of the working group?
>      >
>      >
>      > I thought it was, but I'm not the chair, so m= aybe you could ask
>     Harald or
>      > Stefan.
>
>     I definitely think this is the consensus of the working = group.
>
>
> Can you point out when exactly this consensus was reached? This is new= s
> to me, but I definitely could have missed something.

No I can't really. To be clear, no consensus call (o= r similar) has been
held. But every time this is discussed, what I hear is people agreeing
and no objections. It was discussed a bit, e.g., at the f2f at TPAC last year, if you read the minutes [1] you will find some traces of that
discussion.


And, I don't understand why there would be a debate about this. There
are obviously many who want to define APIs (or constraints) that allow
most use-cases to be met without having to modify the SDP. Why would
anyone have anything against that? If there is anyone who really wants
to modify the SDP instead (I have no clue why, but anyway) they can
still do that.

[1] http://lists.w3.org/Archives/Public/public-webrtc/2012Nov/0072.html

 

I would not disagree that there should not be any de= bate that things that can be done through API should be done through API. M= y question is, was there ever consensus that SDP should be a opaque non mod= ifiable blob which should not be used within the application to control things. Or is SDP just a more advanced A= PI surface that is supposed to be used to implement more advanced scenarios= ? Is this group even suppose to specify what can be modified in by the appl= ication SDP or is it supposed to be an empty set? So, was there ever a consensus that "developers MUST= NOT touch SDP"?

 

_____________
Roman Shpount

 

--_000_57A15FAF9E58F841B2B1651FFE16D281057BD4GENSJZMBX01msgint_-- From pthatcher@google.com Mon Jul 8 08:30:57 2013 Return-Path: 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 4506421F9CF5 for ; Mon, 8 Jul 2013 08:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 rVDrTI6mRJ1r for ; Mon, 8 Jul 2013 08:30:56 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id A6E8E21F9CF3 for ; Mon, 8 Jul 2013 08:30:56 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj3so4515566pad.14 for ; Mon, 08 Jul 2013 08:30:56 -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=EUaNA/040uX7zwmyBDIH0s/pJsgh9g51YdcXsZde9ck=; b=M8DAOLrfT5dBltXNmtNEE8LA+crR4QrSfbPIA+guGtlX2Av9qRgZeRWjg4Zpb/+ESQ yoyfM+EhK9tLK5geNQCtDaQadZ05DuMvpgWVLs3C2wUYFH60+I1QxomaKnQXzipGmBvr 0SPMlHARv+tPzPWK/C8c3iS/6HcRyH3fvCONq3szshtvyaSC7LXa8VVJVlSNsAg6fvCu +A0SPnIj+O8ImKdSV5mzuCR7qCGVHZQTjDqRfvVzpbOJtfvfe49Ab4VL63MsgSuLjeG7 JDTZjwqPRId2S98zWuYrhMOBwAuJsDiYUth+dJT4mP/ZifkJh4KaTanujfnZ3EU64eGE OYRg== 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=EUaNA/040uX7zwmyBDIH0s/pJsgh9g51YdcXsZde9ck=; b=QpVVfmMZiNZOkgN/z4OJ1sJCIYR44/2Q650bvX4Seb3467lJH/oNhQYm7+L9Uk5KNX O5yYxjZshieEiXWYITVfxqqoXY03WyjhdQYlG3mj1l7fHo3WRIzE7MsgXf/IaNdOn3Vq Rju4Wv1HDyHtjfbqdnr3+yKGQLX1FjR4aoFUO7wTnezPLAtEo+0FzDPcjv4mlUHD4Mtf tRHTYtRsWvN7GMGhUPCwAitI5Mf8W9laKcFvE6MV12I2/mQ+nPnxniGeG1npLh8cOrde JaBSUc9mxJL640XhD4Z3H8Z+GvTsMmkEDojH3fMbbb8XUuhycYdPTt5PLAsf5kuSFTzZ QtMg== X-Received: by 10.66.142.5 with SMTP id rs5mr16200145pab.168.1373297456338; Mon, 08 Jul 2013 08:30:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 08:30:16 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> <093EDF0B-AFEA-4979-AC72-23AF2FC5E8C7@oracle.com> From: Peter Thatcher Date: Mon, 8 Jul 2013 08:30:16 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11330f2a0e7bee04e101bbff X-Gm-Message-State: ALoCoQnFux2MrsLrk207KzMyjcj73JcBWhcF7oBUz6I8fBZTRadudny1vtPuUizlT5+OMpZrWEMQYH55nR8Bkt454hjVMAnb+eRntyEcUsE/pw/wg3SYwZR0HoxwXQ35mTvMCdT+hIaVcK1wv6oqM0vFdcq+bzlmplj6+a4yPLN3/m0jR8PMuYUv8pu8CuR6Scf21cVUUOAo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:30:57 -0000 --001a11330f2a0e7bee04e101bbff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 3:20 PM, I=C3=B1aki Baz Castillo wro= te: > 2013/7/3 Hadriel Kaplan : > > You might also want to cite some of the reasons noted in this old draft= : > > http://tools.ietf.org/html/draft-kaplan-rtcweb-api-reqs-01 > > Well, section "3. Defining a WebRTC Protocol in the Browser" says: > > > 9) Using the SDP offer/answer model provides a more rigid API > interaction model, enabling Browser vendors to perform less > testing and provide more robust implementations than exposing all > discrete components to a Javascript API would. > > 10) Using a higher-level API model, such as would be done with an > SDP offer/answer model, means the cross-browser vendor-specific > variances would be reduced. Exposing a lower-level API would > inevitably lead to some differences in different browsers due to > differences in their architectures/implementation. > > > Time to reconsider those assertions? ;) > > > These assertions assume we have only two choices: 1. A high level SDP-based API or 2. A low-level API that "[exposes] all discrete components". Was a "middle ground" API ever considered? One which doesn't require everything go through SDP, and also doesn't expose "all discrete components"? A sort of "best of both worlds" approach? I'd be interested to know if such an ideas was proposed and rejected or simply never proposed. > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11330f2a0e7bee04e101bbff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 3, 2013 at 3:20 PM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
2013/7/3 Hadriel Kaplan <hadriel.kaplan@oracle.com>:
> You might also want to cite some of the reasons noted in this old= draft:
> http://tools.ietf.org/html/draft-kaplan-rtcweb-api-reqs-= 01

Well, section "3. Defining a WebRTC Protocol in the Browser"= ; says:


=C2=A0 =C2=A09) Using the SDP offer/answer model provides a more rigid API<= br> =C2=A0 =C2=A0 =C2=A0interaction model, enabling Browser vendors to perform = less
=C2=A0 =C2=A0 =C2=A0testing and provide more robust implementations than ex= posing all
=C2=A0 =C2=A0 =C2=A0discrete components to a Javascript API would.

=C2=A0 =C2=A010) =C2=A0 Using a higher-level API model, such as would be do= ne with an
=C2=A0 =C2=A0 =C2=A0SDP offer/answer model, means the cross-browser vendor-= specific
=C2=A0 =C2=A0 =C2=A0variances would be reduced. =C2=A0Exposing a lower-leve= l API would
=C2=A0 =C2=A0 =C2=A0inevitably lead to some differences in different browse= rs due to
=C2=A0 =C2=A0 =C2=A0differences in their architectures/implementation.


Time to reconsider those assertions? ;)



These assertions assume we have = only two choices: =C2=A01. =C2=A0A high level SDP-based API or 2. =C2=A0 A = low-level API that "[exposes] all discrete components". =C2=A0=C2= =A0

Was a "middle ground" API ever considered? =C2=A0One which = =C2=A0doesn't require everything go through SDP, and also doesn't e= xpose "all discrete components"? =C2=A0 A sort of "best of b= oth worlds" approach? =C2=A0 I'd be interested to know if such an = ideas was proposed and rejected or simply never proposed.

=C2=A0
--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--001a11330f2a0e7bee04e101bbff-- From roman@telurix.com Mon Jul 8 08:37:49 2013 Return-Path: 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 E730C21F9D17 for ; Mon, 8 Jul 2013 08:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 r2Q7ZWluepMz for ; Mon, 8 Jul 2013 08:37:44 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 50BF521F9D28 for ; Mon, 8 Jul 2013 08:37:42 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so9176035wid.3 for ; Mon, 08 Jul 2013 08:37:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=QMVxSm96dBNCzrv3dIEpQJe4sgGr89WOIDVbXghajZ4=; b=Qe6YRAgCANrtaIY3jJirT7Y7YyUd8tUE/FThkMjqSVOlmRUAWeRzBFuHFSQ53qwLUR 2OlGYgkUYajrMx/7GFdkesgGmet1Z9/MW0TJqHVl85MvNZUbdNGd1U4RmFQKo9DI5+hP f8u7jICQYwqrLdyue2P6onL6xxcCILslscypXc0szdN/neWKHEN+6oinbhZEQzSkXsvT b9P02MSljhylTbczeik0HXthUG8f2Q/ejz/EH+AhHD+3NJEebBqFsQbQ0f3eS+ENhxC5 4mfkuqYOPeDL4sgvytBpSZwl9D22HufgwLDDJkf5wQuoVJkVt19FwtzfpVvpfl9tTvSZ JdnA== X-Received: by 10.180.208.105 with SMTP id md9mr11809841wic.57.1373297862155; Mon, 08 Jul 2013 08:37:42 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [2a00:1450:400c:c03::235]) by mx.google.com with ESMTPSA id u9sm24640364wif.6.2013.07.08.08.37.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 08:37:41 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so3670526wes.26 for ; Mon, 08 Jul 2013 08:37:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.228 with SMTP id kx4mr12437301wjb.33.1373297860560; Mon, 08 Jul 2013 08:37:40 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Mon, 8 Jul 2013 08:37:40 -0700 (PDT) In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D281057BD4@GENSJZMBX01.msg.int.genesyslab.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D281057BD4@GENSJZMBX01.msg.int.genesyslab.com> Date: Mon, 8 Jul 2013 11:37:40 -0400 Message-ID: From: Roman Shpount To: Jim Barnett Content-Type: multipart/alternative; boundary=089e012292e2264e8504e101d3d1 X-Gm-Message-State: ALoCoQnaraeN+DA5b2ICE0DGuE+42ZMmPCzYbGBfRHvV9mMels4USpZvcSa9lWyuqNi4nYtY+2BF Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:37:50 -0000 --089e012292e2264e8504e101d3d1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jul 8, 2013 at 11:29 AM, Jim Barnett wr= ote: > As I recall the consensus, developers are supposed to be able to modify > the SDP, but we needed to specify what parts of the SDP could be modified= . > In other words, there might be some limits to what could be modified, bu= t > we haven=92t yet determined/agreed on what they are.**** > > > This is exactly what I thought. _____________ Roman Shpount --089e012292e2264e8504e101d3d1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 8, 2013 at 11:29 AM, Jim Barnett= <Jim.Barnett@genesyslab.com> wrote:

As I recall the consensus= , developers are supposed to be able to modify the SDP, but we needed to sp= ecify what parts of the SDP could be modified. =A0In other words, there might be some limits to what could be modified, but we haven= =92t yet determined/agreed on what they are.



This is exactly what I thought.
_____________
Roman Shpount
=A0
--089e012292e2264e8504e101d3d1-- From matthew.kaufman@skype.net Mon Jul 8 09:03:10 2013 Return-Path: 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 4FAB421F91A5 for ; Mon, 8 Jul 2013 09:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306] 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 gpNb-T1KcqUJ for ; Mon, 8 Jul 2013 09:03:05 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id EB02121F9B2F for ; Mon, 8 Jul 2013 09:03:00 -0700 (PDT) Received: from BN1BFFO11FD010.protection.gbl (10.58.52.202) by BN1AFFO11HUB026.protection.gbl (10.58.52.136) with Microsoft SMTP Server (TLS) id 15.0.717.3; Mon, 8 Jul 2013 16:02:59 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD010.mail.protection.outlook.com (10.58.53.70) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Mon, 8 Jul 2013 16:02:59 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.166]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0136.001; Mon, 8 Jul 2013 16:02:49 +0000 From: "Matthew Kaufman (SKYPE)" To: Peter Thatcher , Silvia Pfeiffer Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model Thread-Index: AQHOcibWHlwQV9Ag60yH3THnpGmGQ5lXi5CAgANn9YCAABEzsA== Date: Mon, 8 Jul 2013 16:02:48 +0000 Message-ID: References: <51CA6FEE.6030702@hookflash.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A308833tk5ex14mbxc272r_" 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)(199002)(51704005)(24454002)(377454003)(33656001)(74662001)(47736001)(81542001)(561944002)(512874002)(6806003)(56776001)(76482001)(79102001)(81342001)(47446002)(77982001)(74366001)(51856001)(50986001)(46102001)(59766001)(49866001)(47976001)(4396001)(15202345003)(65816001)(74706001)(80022001)(54356001)(71186001)(63696002)(76786001)(53806001)(16297215004)(16236675002)(76796001)(19300405004)(77096001)(16406001)(55846006)(69226001)(83072001)(74502001)(20776003)(56816003)(74876001)(66066001)(54316002)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB026; 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: 09011458FC Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:03:10 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A308833tk5ex14mbxc272r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29tZSBvZiB1cyB3b3JrIGZvciBicm93c2VyIHZlbmRvcnMgd2hvIGNhbm5vdCBmb2xsb3cgdGhh dCBsaW5rLCB5b3Uga25vdy4NCg0KTWF0dGhldyBLYXVmbWFuDQoNCkZyb206IHJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBQZXRlciBUaGF0Y2hlcg0KU2VudDogTW9uZGF5LCBKdWx5IDgsIDIwMTMgODowMSBBTQ0KVG86 IFNpbHZpYSBQZmVpZmZlcg0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3 ZWJdIE5ldyBEcmFmdCAtIFdlYlJUQyBKUyBPYmplY3QgQVBJIE1vZGVsDQoNCg0KDQpPbiBTYXQs IEp1bCA2LCAyMDEzIGF0IDM6NTkgQU0sIFNpbHZpYSBQZmVpZmZlciA8c2lsdmlhcGZlaWZmZXIx QGdtYWlsLmNvbTxtYWlsdG86c2lsdmlhcGZlaWZmZXIxQGdtYWlsLmNvbT4+IHdyb3RlOg0KQW4g aW50ZXJlc3RpbmcgcmVhZC4gSXQgbWFrZXMgbWUgd29uZGVyIGlmIHRoZXJlIGlzIGEgZnVsbCBk ZXNjcmlwdGlvbg0KYXZhaWxhYmxlIG9mIHRoZSBTRFAgdGhhdCBicm93c2VycyAoQ2hyb21lLCBG aXJlZm94KSBjdXJyZW50bHkNCnN1cHBvcnQuDQoNCkhlcmUncyB0aGUgZGVzY3JpcHRpb24gZm9y IENocm9tZToNCg0KaHR0cHM6Ly9jb2RlLmdvb2dsZS5jb20vcC9saWJqaW5nbGUvc291cmNlL2Jy b3dzZS90cnVuay90YWxrL2FwcC93ZWJydGMvd2VicnRjc2RwLmNjDQoNCjopDQoNCg0KTG9va2lu ZyBmb3J3YXJkIHRvIHlvdXIgcHJvcG9zYWwgKEkgYXNzdW1lIGl0IHdpbGwgYmUgb24gdGhlIFcz QyBsaXN0PykuDQoNCkNoZWVycywNClNpbHZpYS4NCg0KT24gV2VkLCBKdW4gMjYsIDIwMTMgYXQg MjozNyBQTSwgUm9iaW4gUmF5bW9uZCA8cm9iaW5AaG9va2ZsYXNoLmNvbTxtYWlsdG86cm9iaW5A aG9va2ZsYXNoLmNvbT4+IHdyb3RlOg0KPg0KPiBBY2NvcmRpbmcgdG8gbWFueSwgcmVhbCBhZG9w dGlvbiBvZiBXZWJSVEMgd2lsbCBub3QgaGFwcGVuIGlmIHdlIGNvbnRpbnVlIHRvDQo+IGZvcmNl IGV2ZXJ5b25lIHRvIHVzZSB0aGlzIFNEUCBPZmZlci9BbnN3ZXIgbWV0aG9kb2xvZ3kuICBJdCBp cyBjbGVhcmx5DQo+IGJsb2NraW5nIG91ciB3YXkgZm9yd2FyZCBhbmQgdGhlIGFtb3VudCBvZiBz cGVjaWZpY2F0aW9uIGRvY3VtZW50YXRpb24NCj4gcmVtYWluaW5nIG5lZWRlZCBmb3IgdGhlIGJy b3dzZXIgdmVuZG9ycyB0byBwcm9kdWNlIGEgY29tcGF0aWJsZSBTRFAgYmFzZWQNCj4gV2ViUlRD IGVuZ2luZSBpbiBhIGJyb3dzZXIgaXMgbXVjaCBtb3JlIGRhdW50aW5nIHRoYW4gbW9zdCBhcmUg d2lsbGluZyB0bw0KPiBhZG1pdC4NCj4NCj4NCj4gVGhlIGRyYWZ0IHJhdGlvbmFsZSBiZWhpbmQg YSBKYXZhU2NyaXB0IE9iamVjdCBBUEkgbW9kZWw6DQo+DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJheW1vbmQtcnRjd2ViLXdlYnJ0Yy1qcy1vYmotYXBpLXJh dGlvbmFsZS0wMC50eHQNCj4NCj4gV2hlcmVhczoNCj4NCj4gVGhlIFdlYlJUQyBKYXZhU2NyaXB0 IE9iamVjdCBBUEkgJiBTaGltIGRvY3VtZW50IHdpbGwgYmUgYWxvbmcgc2hvcnRseS4NCj4NCj4N Cj4gV2Ugd2FudGVkIHRvIGdldCB0aGlzIGluaXRpYWwgcmF0aW9uYWxlIGRyYWZ0IGluZm9ybWF0 aW9uYWwgZG9jdW1lbnQgb3V0DQo+IHJpZ2h0IGF3YXkuIEV2ZXJ5b25lIHRoYXQgaGFzIGFueSBp bnRlcmVzdCBzaG91bGQgcmV2aWV3IHRoZSByZWFzb25zIGFuZA0KPiBjb25jZXB0cyBhbmQgY29t bWVudCBiZWZvcmUgd2UgZ2V0IHRvbyBmYXIgYWxvbmcgb24gdGhlIGRldGFpbHMgb2YgYW4gYWN0 dWFsDQo+IEFQSSwgdGhlIGluaXRpYWwgQVBJIHdpbGwgZm9sbG93IGluIHRoZSBjb21pbmcgZGF5 cy4NCj4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPg0KPiBSb2JpbiBSYXltb25kDQo+DQo+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dlYiBt YWlsaW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcg bGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A308833tk5ex14mbxc272r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+U29tZSBvZiB1cyB3b3JrIGZvciBicm93c2VyIHZlbmRvcnMgd2hv IGNhbm5vdCBmb2xsb3cgdGhhdCBsaW5rLCB5b3Uga25vdy48bzpwPjwvbzpwPjwvc3Bhbj48L2E+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXR0aGV3 IEthdWZtYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBy dGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5QZXRlciBUaGF0Y2hlcjxicj4NCjxiPlNlbnQ6PC9iPiBNb25k YXksIEp1bHkgOCwgMjAxMyA4OjAxIEFNPGJyPg0KPGI+VG86PC9iPiBTaWx2aWEgUGZlaWZmZXI8 YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3J0Y3dlYl0gTmV3IERyYWZ0IC0gV2ViUlRDIEpTIE9iamVjdCBBUEkgTW9kZWw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBTYXQsIEp1bCA2LCAyMDEzIGF0IDM6NTkgQU0sIFNpbHZpYSBQZmVpZmZlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNpbHZpYXBmZWlmZmVyMUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5zaWx2aWFwZmVpZmZlcjFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW4gaW50ZXJlc3RpbmcgcmVhZC4g SXQgbWFrZXMgbWUgd29uZGVyIGlmIHRoZXJlIGlzIGEgZnVsbCBkZXNjcmlwdGlvbjxicj4NCmF2 YWlsYWJsZSBvZiB0aGUgU0RQIHRoYXQgYnJvd3NlcnMgKENocm9tZSwgRmlyZWZveCkgY3VycmVu dGx5PGJyPg0Kc3VwcG9ydC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUncyB0aGUgZGVzY3JpcHRpb24gZm9yIENocm9tZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg aHJlZj0iaHR0cHM6Ly9jb2RlLmdvb2dsZS5jb20vcC9saWJqaW5nbGUvc291cmNlL2Jyb3dzZS90 cnVuay90YWxrL2FwcC93ZWJydGMvd2VicnRjc2RwLmNjIj5odHRwczovL2NvZGUuZ29vZ2xlLmNv bS9wL2xpYmppbmdsZS9zb3VyY2UvYnJvd3NlL3RydW5rL3RhbGsvYXBwL3dlYnJ0Yy93ZWJydGNz ZHAuY2M8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjopPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCkxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIHByb3Bvc2FsIChJIGFz c3VtZSBpdCB3aWxsIGJlIG9uIHRoZSBXM0MgbGlzdD8pLjxicj4NCjxicj4NCkNoZWVycyw8YnI+ DQpTaWx2aWEuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCk9uIFdlZCwgSnVuIDI2LCAyMDEzIGF0IDI6MzcgUE0sIFJvYmluIFJheW1vbmQg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb2JpbkBob29rZmxhc2guY29tIj5yb2JpbkBob29rZmxhc2gu Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgQWNjb3JkaW5nIHRvIG1hbnks IHJlYWwgYWRvcHRpb24gb2YgV2ViUlRDIHdpbGwgbm90IGhhcHBlbiBpZiB3ZSBjb250aW51ZSB0 bzxicj4NCiZndDsgZm9yY2UgZXZlcnlvbmUgdG8gdXNlIHRoaXMgU0RQIE9mZmVyL0Fuc3dlciBt ZXRob2RvbG9neS4gJm5ic3A7SXQgaXMgY2xlYXJseTxicj4NCiZndDsgYmxvY2tpbmcgb3VyIHdh eSBmb3J3YXJkIGFuZCB0aGUgYW1vdW50IG9mIHNwZWNpZmljYXRpb24gZG9jdW1lbnRhdGlvbjxi cj4NCiZndDsgcmVtYWluaW5nIG5lZWRlZCBmb3IgdGhlIGJyb3dzZXIgdmVuZG9ycyB0byBwcm9k dWNlIGEgY29tcGF0aWJsZSBTRFAgYmFzZWQ8YnI+DQomZ3Q7IFdlYlJUQyBlbmdpbmUgaW4gYSBi cm93c2VyIGlzIG11Y2ggbW9yZSBkYXVudGluZyB0aGFuIG1vc3QgYXJlIHdpbGxpbmcgdG88YnI+ DQomZ3Q7IGFkbWl0Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZHJhZnQgcmF0 aW9uYWxlIGJlaGluZCBhIEphdmFTY3JpcHQgT2JqZWN0IEFQSSBtb2RlbDo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1yYXltb25kLXJ0Y3dlYi13ZWJydGMtanMtb2JqLWFwaS1yYXRpb25hbGUtMDAudHh0IiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1y YXltb25kLXJ0Y3dlYi13ZWJydGMtanMtb2JqLWFwaS1yYXRpb25hbGUtMDAudHh0PC9hPjxicj4N CiZndDs8YnI+DQomZ3Q7IFdoZXJlYXM6PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIFdlYlJUQyBK YXZhU2NyaXB0IE9iamVjdCBBUEkgJmFtcDsgU2hpbSBkb2N1bWVudCB3aWxsIGJlIGFsb25nIHNo b3J0bHkuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIHdhbnRlZCB0byBnZXQgdGhp cyBpbml0aWFsIHJhdGlvbmFsZSBkcmFmdCBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IG91dDxicj4N CiZndDsgcmlnaHQgYXdheS4gRXZlcnlvbmUgdGhhdCBoYXMgYW55IGludGVyZXN0IHNob3VsZCBy ZXZpZXcgdGhlIHJlYXNvbnMgYW5kPGJyPg0KJmd0OyBjb25jZXB0cyBhbmQgY29tbWVudCBiZWZv cmUgd2UgZ2V0IHRvbyBmYXIgYWxvbmcgb24gdGhlIGRldGFpbHMgb2YgYW4gYWN0dWFsPGJyPg0K Jmd0OyBBUEksIHRoZSBpbml0aWFsIEFQSSB3aWxsIGZvbGxvdyBpbiB0aGUgY29taW5nIGRheXMu PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBSb2JpbiBSYXltb25kPGJyPg0KJmd0Ozxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 IHJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KJmd0Ozxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRj d2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0 Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A308833tk5ex14mbxc272r_-- From ekr@rtfm.com Mon Jul 8 09:18:53 2013 Return-Path: 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 9C05521F9C10 for ; Mon, 8 Jul 2013 09:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 2bxWNX3viqbc for ; Mon, 8 Jul 2013 09:18:47 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id B1D4D21F9C0A for ; Mon, 8 Jul 2013 09:18:47 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id a11so2447574qen.10 for ; Mon, 08 Jul 2013 09:18:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=dTtgg0KONTrlrIIYRQMfxpjAEvjILkoUmfkwH/ky5S0=; b=eOqExiKqo2PXzTrVlCUyvVu2hMLlTKsm+VSr9AudcO603niVF0x7yema9zBHVJ/PBE bNxUo5MSK7czOXhDbaoWjl1yS3l6uXQ9ec9rnylAjD43jV+0SV2xS6Bby+ZUbpisuWYi hTSTkcV9YZA5FXlSc5KYRSF7HkJv0bGEFUHP5CGS9ZWiY4dMWWNv7wJAm7cW5sVfoJQY DCVYXtAeFXr5quxW85pRkdsxa4s+LCz7Am0QpyKi94TDc8PLtx9+se98xwx7gzu8SYMP VfsL3atooPc/xW16+kzniQT0qIOANWQPcdy9uZcEOiI6phDl7cS3A1cEzqEy5vHHbhKt w8TQ== X-Received: by 10.224.115.5 with SMTP id g5mr19491390qaq.53.1373300327073; Mon, 08 Jul 2013 09:18:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Mon, 8 Jul 2013 09:18:07 -0700 (PDT) X-Originating-IP: [63.245.219.150] In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D281057BD4@GENSJZMBX01.msg.int.genesyslab.com> From: Eric Rescorla Date: Mon, 8 Jul 2013 09:18:07 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=047d7bdc95142a570b04e102661c X-Gm-Message-State: ALoCoQlSdj1xE8CcOnu3b8N0jFw0qKwR7/u285XV4LWL/7sum7Io+qeuzWBUrvFrwBV80m/otgGU Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:18:53 -0000 --047d7bdc95142a570b04e102661c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Y On Mon, Jul 8, 2013 at 8:37 AM, Roman Shpount wrote: > > On Mon, Jul 8, 2013 at 11:29 AM, Jim Barnett = wrote: > >> As I recall the consensus, developers are supposed to be able to modify >> the SDP, but we needed to specify what parts of the SDP could be modifie= d. >> In other words, there might be some limits to what could be modified, b= ut >> we haven=92t yet determined/agreed on what they are.**** >> >> >> > This is exactly what I thought. > > Yes, this matches my understanding as well. However, I believe there was also general agreement that most things one would want to do should be doable without modifying SDP. -Ekr --047d7bdc95142a570b04e102661c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Y


On Mon, Jul 8, 2013 at 8:37 AM, Roman Shpount &l= t;roman@telurix.com<= /a>> wrote:

On Mon, Jul 8, 2013 at 11:29 AM, Jim Barnett <Jim.Barnett@ge= nesyslab.com> wrote:

As I recall the consensus= , developers are supposed to be able to modify the SDP, but we needed to sp= ecify what parts of the SDP could be modified. =A0In other words, there might be some limits to what could be modified, but we haven= =92t yet determined/agreed on what they are.



This is exactly what I thought.

Yes, this matches my understanding as well. However, I believ= e there was also
general agreement that most things one would want to do should b= e
doable without modifying SDP.

<= div style>-Ekr
=A0
--047d7bdc95142a570b04e102661c-- From roman@telurix.com Mon Jul 8 09:32:43 2013 Return-Path: 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 2EC9021F9CB3 for ; Mon, 8 Jul 2013 09:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] 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 4M39DA6HrutQ for ; Mon, 8 Jul 2013 09:32:29 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id BED8B21F8EEA for ; Mon, 8 Jul 2013 09:32:28 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so9078177wgg.4 for ; Mon, 08 Jul 2013 09:32:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=BCn3pcvDA1LvpycK5hhimWy4JzagX6FC/QXPwRXxeGo=; b=Fr8S4HN/FvWBe1b4QOOA74rLLBLdkqZu4PIRC0PZhxbkE4M56rQpiIM+lv049J9Sav A9E8Szc9HO+p2QSCIIS83//YrP7Mtsj/ktecncGQNU4KAN2I1Xmso7k4j+7JoZ/0YboH eq1kF02YkWnmG2SGQOsz8DIgWyLK2/Xq7ysu1nbYxuCnSmXCI33RAcZJwt0SrkuGDqq/ RmvuJ2iKTk9/KK1yCuJ7K76TtixeGZnd0zWj8CenkLn9YY3RQD27V4sI8uXpX85Jr+SY BpcbKgvGeSATVL5Xx3VXb69bB3MTFEav5HrtFT6TdwsjiHUx8KMInY1pf1fapVUFNjCm b2jA== X-Received: by 10.194.240.169 with SMTP id wb9mr12248300wjc.90.1373301147812; Mon, 08 Jul 2013 09:32:27 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [2a00:1450:400c:c03::232]) by mx.google.com with ESMTPSA id fb9sm56214433wid.2.2013.07.08.09.32.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 09:32:27 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so3778607wes.23 for ; Mon, 08 Jul 2013 09:32:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.173.71 with SMTP id bi7mr12756439wjc.2.1373301146083; Mon, 08 Jul 2013 09:32:26 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Mon, 8 Jul 2013 09:32:25 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D281057BD4@GENSJZMBX01.msg.int.genesyslab.com> Date: Mon, 8 Jul 2013 12:32:25 -0400 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0112cf9afb6a9704e1029637 X-Gm-Message-State: ALoCoQnfkbgQRabBiORNGx3o2kZa2vHXmD5hWl8qOHTYPCDV6zUGYlqAU1vxWThggXip8537spj7 Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:32:43 -0000 --089e0112cf9afb6a9704e1029637 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 8, 2013 at 12:18 PM, Eric Rescorla wrote: > Yes, this matches my understanding as well. However, I believe there was > also > general agreement that most things one would want to do should be > doable without modifying SDP. > "Should be doable" being the operative word. We are not there yet. We need both new API types (like capabilites) and more settings for existing API methods(more constraints).This also means either a lot of API extensions in the future (with new API extension for each new SDP based feature) or always having SDP as a fallback API surface. If this is done right we can just keep constraints and get rid of SDP altogether. ______________ Roman Shpount --089e0112cf9afb6a9704e1029637 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 8, 2013 at 12:18 PM, Eric Rescorla <= span dir=3D"ltr"><ekr@= rtfm.com> wrote:
Yes, this matches my understanding as well. However, I believe there was a= lso
general agreement that most things one would want to do should be
doable without modifying SDP.
=A0

"Should be doable" being the opera= tive word. We are not there yet. We need both new API types (like capabilit= es) and more settings for existing API methods(more constraints).This also = means either a lot of API extensions in the future (with new API extension = for each new SDP based feature) or always having SDP as a fallback API surf= ace. =A0If this is done right we can just keep constraints and get rid of S= DP altogether.

______________
Roman Shpount
--089e0112cf9afb6a9704e1029637-- From ekr@rtfm.com Mon Jul 8 09:42:42 2013 Return-Path: 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 31A7A21F9DAA for ; Mon, 8 Jul 2013 09:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 P38DEmed0J-c for ; Mon, 8 Jul 2013 09:42:20 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF4D21F99B7 for ; Mon, 8 Jul 2013 09:42:17 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so2419145qcy.18 for ; Mon, 08 Jul 2013 09:41:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=VyXZSdwk1lypm3CsiQboZFfnrr70TNVSXYJQcQYufDE=; b=WzTQy64mumIuOxnCqxTzWrZ8kwJGXtpRUU2XkHqEZYR30W6NvGG8ow2ubSulpAxNQn e5STUM6+4iC+ho5AmaG7Qe3NrveTWfZgZez1npHFa8P0+kpwa1UOHnVaUVVxuD/Ok/VY 6YR9TcCFMyrkUEOWgVTsxMutJV8Ajisxjrw7qH8FWh0dLIRtvgvcpVFOTBVa/Xc2HA5z MUuz+vzzyBy8eYql8Phgf4e2L0qON8lJLub+m8NrpLirSjZbthYb2LCAmIiuY4Utue8n 9HZnkCyxG4TYFf7UbAfif4Z0pvlx+oaDtN4uoMNriHJdNFR0QCSWyDBIVwNN4IxcpF3y jLpw== X-Received: by 10.49.116.9 with SMTP id js9mr17222567qeb.73.1373301717912; Mon, 08 Jul 2013 09:41:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Mon, 8 Jul 2013 09:41:17 -0700 (PDT) X-Originating-IP: [63.245.219.150] In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D281057BD4@GENSJZMBX01.msg.int.genesyslab.com> From: Eric Rescorla Date: Mon, 8 Jul 2013 09:41:17 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=047d7b6da78210e1b204e102b9af X-Gm-Message-State: ALoCoQksgSunGyE+gNsSNBjKIRk7Ci0IUct3Q++LH+DoTQ6I2lKeLiN1nXZy2cWHOnus9CB2josd Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:42:50 -0000 --047d7b6da78210e1b204e102b9af Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 8, 2013 at 9:32 AM, Roman Shpount wrote: > On Mon, Jul 8, 2013 at 12:18 PM, Eric Rescorla wrote: > >> Yes, this matches my understanding as well. However, I believe there was >> also >> general agreement that most things one would want to do should be >> doable without modifying SDP. >> > > > "Should be doable" being the operative word. We are not there yet. We need > both new API types (like capabilites) and more settings for existing API > methods(more constraints). > Yes, I agree with that. What would be useful would be for people to make a list of these use cases and the extensions which would enable them. -Ekr --047d7b6da78210e1b204e102b9af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 8, 2013 at 9:32 AM, Roman Shpount <= ;roman@telurix.com> wrote:
On Mon, Jul 8, 2013 at 12:18 PM, Eric Rescorla <ekr@rtfm.com> wr= ote:
Yes, this matches my understanding as well. However, I believe there was a= lso
general agreement that most things one would want to do should be
doable without modifying SDP.
=A0

"Should be doable" being the= operative word. We are not there yet. We need both new API types (like cap= abilites) and more settings for existing API methods(more constraints).

Yes, I agree with that. What w= ould be useful would be for people to
make a list of these = use cases and the extensions which would
enable them.

-Ekr

<= br>
=A0
--047d7b6da78210e1b204e102b9af-- From martin.thomson@gmail.com Mon Jul 8 09:48:05 2013 Return-Path: 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 1B90D21F9D8E for ; Mon, 8 Jul 2013 09:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 QQ+k4HPOthfl for ; Mon, 8 Jul 2013 09:48:04 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9821F9D7F for ; Mon, 8 Jul 2013 09:48:04 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so3931147wes.3 for ; Mon, 08 Jul 2013 09:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UIRRy7IsdBz1z5a+0lgsLUhhEtuBe+TXMWVEiuUcHkA=; b=n3a01CbkBHhQ0a0NTttVPUhyZRQYo1cDi0P9IRFFf7BLOcoQAszLHhmT2FOUQqh4nj jiA2tIOqB8LYnfRBWrYqVCNWiDyY1+GxhnNm9tKkNj+ijEkRIT7OWgbRGe6ZJ3h0vvMQ i4x5geelUwsWCyIVGWPL3Wm21m8GXabF139Tr0AnTZGu8wsGMr3cvZe3mjHJV62XnuUz q5VAFph6eVIg7whYBM1EUyL6ZeGn2wbJWmpKIEprG80bINMngQG2RsOmVT1rfSvfjtGU xuJKv1WkScawfxmVTqK3yAihtgpZSZotXioRBXQoFmAIsC1ixYv8jqIXuI5zhMK7EWpn eBxg== MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr11967642wic.65.1373302082535; Mon, 08 Jul 2013 09:48:02 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 8 Jul 2013 09:48:02 -0700 (PDT) In-Reply-To: <51DAAF4B.4070004@viagenie.ca> References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DAAF4B.4070004@viagenie.ca> Date: Mon, 8 Jul 2013 09:48:02 -0700 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:48:05 -0000 Two separate replies... On 8 July 2013 05:23, Simon Perreault wrote: > Le 2013-07-08 06:24, Justin Uberti a =C3=A9crit : >> Just uploaded a 00 version of a spec for requesting time-limited TURN >> credentials for WebRTC apps. Would like to get 10 minutes of agenda time >> to present this in Berlin. Justin, is this the right working group for this draft? Presumably, you want to talk to whoever owns TURN, which is (I believe) behave. > One small comment: shouldn't the response also contain the value of the > REALM parameter? I assume that this is intended to use the short term credential mechanism. No need to use long term credentials in this case. From roman@telurix.com Mon Jul 8 10:02:22 2013 Return-Path: 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 65E8F21F9C8B for ; Mon, 8 Jul 2013 10:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 J-w5DeTkyhVU for ; Mon, 8 Jul 2013 10:02:17 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 87FC821F9C7A for ; Mon, 8 Jul 2013 10:02:16 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so3953383wes.10 for ; Mon, 08 Jul 2013 10:02:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=x0z66iIc+BYyWXDNV5nbWQHPvykmxxnTUAgaGeeSj28=; b=iV93+irLc1Nbz80db3B+8dCDcDzsuxFOSyibJ35sd018v971bApPcx7bWpCvU8BOsh DEmHzVLOiApjjuvtjf32bT0iRRryY5D/pY42YXLzM6G3UiVTGSUDdIxsLOc5p2MEDq3v 6LGu3oInbEIPBXiGKCKGAMoIp1i/U7OkkzjhR3ORGx99EapTTRrrOnSIT6jh5O3lCOyb f9XskQJut979srsOi4h28bVOgjq5/xXetLnXi8oiFPrXox7DZi7ytcVdwFUB3xYXy6Ez evcOGDssRozeWxQpEPF1E4KP2AOgopCb8t5JCeR77ZNBUN2NFZJr1QZFV1dwbpcyWBCp /z4g== X-Received: by 10.194.80.134 with SMTP id r6mr12850780wjx.88.1373302932785; Mon, 08 Jul 2013 10:02:12 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [2a00:1450:400c:c00::229]) by mx.google.com with ESMTPSA id d8sm25142246wiz.0.2013.07.08.10.02.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 10:02:12 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so9102921wgg.0 for ; Mon, 08 Jul 2013 10:02:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.184.12 with SMTP id eq12mr11949351wic.8.1373302931133; Mon, 08 Jul 2013 10:02:11 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Mon, 8 Jul 2013 10:02:11 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D281057BD4@GENSJZMBX01.msg.int.genesyslab.com> Date: Mon, 8 Jul 2013 13:02:11 -0400 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c3669e611cc204e1030124 X-Gm-Message-State: ALoCoQlxzFUHQa/hfJ7O6Kqv+HsAYBtDNy4yHObg4X4BCBRg3EdBHsjPt10ed0tx1Fw//FbVNEeJ Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 17:02:22 -0000 --001a11c3669e611cc204e1030124 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 8, 2013 at 12:41 PM, Eric Rescorla wrote: > > What would be useful would be for people to > make a list of these use cases and the extensions which would > enable them. > > This would be ability to modify all the information present in SDP. So the rule of thumb should be that if you can remove SDP from the API call, then you have done it right. For me personally I would like to see: 1. Specify codec list including relative priorities, framerate, number of channels, and per codec parameters (like useinbandfec for OPUS). 2. Specify ptimes and maxptime per media stream and per codec 3. Specify bandwidth per media stream 4. If we support SDES SRTP, specify encryption profiles _____________ Roman Shpount --001a11c3669e611cc204e1030124 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 8, 2013 at 12:41 PM, Eric Rescorla <= span dir=3D"ltr"><ekr@= rtfm.com> wrote:

=
What would be useful would be for people to
make a list of t= hese use cases and the extensions which would
enable them.


This woul= d be ability to modify all the information present in SDP. So the rule of t= humb should be that if you can remove SDP from the API call, then you have = done it right.

For me personally I would like to see:
1. Spe= cify codec list including relative priorities, framerate, number of channel= s, and per codec parameters (like=A0useinband= fec for OPUS).
2. Specify ptimes and maxptime per media stream and per codec
3. Specify bandwidth per media stream
4. If we support SDES SRT= P, specify encryption profiles
_____________
Roman Shpount
=A0
--001a11c3669e611cc204e1030124-- From ibc@aliax.net Mon Jul 8 10:07:19 2013 Return-Path: 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 6E2CB21F9D07 for ; Mon, 8 Jul 2013 10:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Ildmp77MJB7N for ; Mon, 8 Jul 2013 10:07:14 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4951121F9DC1 for ; Mon, 8 Jul 2013 10:07:14 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so2371576qab.18 for ; Mon, 08 Jul 2013 10:07:13 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=yiGQBwY9KIU4qAFZcntf7vOUQwZUruMmf8GNM1/1qjY=; b=QiXjpfKIAnp3AU5P39Vhdb5xHticQYdiaasZSinFPK/M9rjKOm1izn4hfAQbNCaoH8 IFIxlvHah39ZbIp23MvqDA96BZagtol0/tycjL82/ylMHZLLnepcbc6tTwv6xRy11FEl jqATOYjoAN3bGWk1WUArcWaDb+G8tqxAzTgBMDC56E4rp//XS7gdKX0W72PbJAU+C8Cz spUDZOQnYWq60cwqM7UhQS3cOVuO71M3MpzsVLK6g4v34o0+dhadYpsE2TOjbS/gaYsp 2+aLLt/uFaUGklownjIPPdOyrrNsWIj7E/fE+w2NDwBbvjVpE0YXEI/ZomJtSnGlsJ1b bI+g== X-Received: by 10.229.206.2 with SMTP id fs2mr3895188qcb.68.1373303233739; Mon, 08 Jul 2013 10:07:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 8 Jul 2013 10:06:52 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Jul 2013 19:06:52 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkK+qW9Jax384+WFsGJ3Dm5k8/a6TysS7tyk6Jod2CPlrKhHPaSHjI2m9/VvZ3s7ARB1l+t Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 17:07:19 -0000 2013/7/8 Stefan H=C3=A5kansson LK : > And, I don't understand why there would be a debate about this. There > are obviously many who want to define APIs (or constraints) that allow > most use-cases to be met without having to modify the SDP. Why would > anyone have anything against that? If there is anyone who really wants > to modify the SDP instead (I have no clue why, but anyway) they can > still do that. This sounds to me like "SDP will be here forever because it was talked about two years ago, but let us improve it by adding some more API methods so there is no need to parse/mangle it". Just to clarify: - Some of us don't want a better API for the currently proposed SDP-based s= pec. - SDP must be parsed/mangled anyway if you want a JS WebRTC app that talks Jingle XEP 0167, so there is no "API improvement" that would avoid such a pain. - It's not just SDP but also the mandate of SDP O/A. What I think is that it is not well understood that SDP O/A is an artificial constrain introduced in WebRTC just because SIP phones do that ***at application level*** (so you are mandating that *any* WebRTC application in the future must play like-SIP rules and SDP O/A model, which is insane). A better and more complete API for the current spec DOES NOT avoid this artificial limitation. In short: some of us DO NOT want a better JS API for the current opaque-unmanageable-SDP-blob based "API". Period. We strongly consider it can be done really better by throwing out SDP and SDP O/A and by providing a *real* JS Objects based API. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jul 8 10:15:29 2013 Return-Path: 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 9339021F977A for ; Mon, 8 Jul 2013 10:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 Z38LV3o41jxD for ; Mon, 8 Jul 2013 10:15:24 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFAD21F972C for ; Mon, 8 Jul 2013 10:15:24 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e10so2394080qcy.41 for ; Mon, 08 Jul 2013 10:15:23 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=E93Z4/CMmoFiGNbRbJfeEdVBfyCgoIL1zQFCjkV/+2o=; b=S/yRiVgsIrmXEKNHqX3vKWyQMN5Zwq09vxiAjHFBqSQKXkUEBabsGNV4JxQpknVhMo 8fAclVGxBdQfXrG3fzwKqUErYjc0584sUBDIWjoQjoLXmDYK0KVFBDRgEz7RTGhnX2fh ztigjuPIvB5DP+sOuJGyJYVwrJhAgDpB2J3N5jqN/hlyKK/VWxMR7ufE9DkCOuOPacnD TLT+VcapiDzVLulZSgsunck03OPVYuIrB4WJvJwZRzyE/3hirUG8yqLH4dYKpf8DzeB6 8wWcQVGsE1yqdmjnT62xknvxlwgX9eg+kIxPxF0S9aqhbnhfFuZR0DgxMBm7t7vZCHgJ 0BJA== X-Received: by 10.224.182.79 with SMTP id cb15mr19899628qab.48.1373303723648; Mon, 08 Jul 2013 10:15:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 8 Jul 2013 10:15:03 -0700 (PDT) In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D281057BD4@GENSJZMBX01.msg.int.genesyslab.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <57A15FAF9E58F841B2B1651FFE16D281057BD4@GENSJZMBX01.msg.int.genesyslab.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Jul 2013 19:15:03 +0200 Message-ID: To: Jim Barnett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnYPGYKa5ZarAd8dVev2ne035/tnIQyYsIGQ3VfGicP5GUm57AFBBhjBaYEHae6Fv6XpEgJ Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 17:15:29 -0000 2013/7/8 Jim Barnett : > As I recall the consensus, developers are supposed to be able to modify t= he > SDP, but we needed to specify what parts of the SDP could be modified. I= n > other words, there might be some limits to what could be modified, but we > haven=E2=80=99t yet determined/agreed on what they are. At this rate, wasting so long time on extending SDP to fullfil WebRTC requirements, it would be done within the next 3-4 years. SDP is the main issue delaying WebRTC 1.0. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jul 8 10:32:21 2013 Return-Path: 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 C6BFC21F9D7C for ; Mon, 8 Jul 2013 10:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 aAph3xUY9hAz for ; Mon, 8 Jul 2013 10:32:16 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id A1F3621F9D71 for ; Mon, 8 Jul 2013 10:32:16 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id n1so2401981qcx.22 for ; Mon, 08 Jul 2013 10:32:15 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=kgPY455xMm1LwuQI65HK3QMTVnr2ihJBwCn97EMQ32s=; b=Q557x+WLfQn3OzjOIsIp2Yn0to3v8k99d2dJGySAxqQf+C3gWT3x68GcAJSpOCzi0v RqshnWYETSaljtHEWOFvdHxIFguhccj73MqHKoMzqQwqRY7bOTyp2Mvn/JlZRrRJVxg2 uf835EvuHFG33JD91I1tO3wjDE+oO2AcTwGUFrByxi/rJO82Mc76CrimbT/eE32X0FeN 5V4HfnzVTKFhmk0UbQqZyTC2t0c1OaGHQJJPNqXKCvKIOkDLt+cDx4FyaUzVw63zgBVH +g5/BTFZHk/Diogf+m5Q9NLoUq71M4ahMFXP8mP0kcafLf2AltNkOPNkyP9oFfVVZwW6 34NA== X-Received: by 10.224.90.1 with SMTP id g1mr20283441qam.0.1373304735911; Mon, 08 Jul 2013 10:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 8 Jul 2013 10:31:55 -0700 (PDT) In-Reply-To: <518BC17C.7030806@alum.mit.edu> References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com> <518AAAF2.5000207@alum.mit.edu> <518BC17C.7030806@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Jul 2013 19:31:55 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnb0cRHL3ssiHWsFv/wnVAQc2xi+zM6hwacyaGMKhGsVDcfp6lxIfQQ9YY3PO69oPh9ELTk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 17:32:22 -0000 2013/5/9 Paul Kyzivat : > Whatever signaling is used to indicate bundling usage in SDP in RTCWEB > should be consistent with what is used in clue. It would be unpleasant if= we > had to have a translator in the web server that must translate one SDP > notation to another. Hi, Give a powerfiul real JavaScript Object based API (instead of an opaque SDP blob) and let the web developer decide whether to construct **via JavaScript** a CLUE compatible SDP or not (just if he needs that), and we all will win. In contrast, by mandating plain SDP (just because SIP uses it) we have to have a translator in the web server that must translate plain-SDP to XML-SDP (in Jingle XEP 0167 deployments), or build the best SDP parser at JS level to parse the SDP blob created by the browser and convert it into XML, and then convert it back into plain SDP. Best regards. -- I=C3=B1aki Baz Castillo From juberti@google.com Mon Jul 8 11:02:33 2013 Return-Path: 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 3452A21F9C61 for ; Mon, 8 Jul 2013 11:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.357 X-Spam-Level: X-Spam-Status: No, score=-1.357 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 leTgQ722M1GJ for ; Mon, 8 Jul 2013 11:02:32 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4449A21F9C58 for ; Mon, 8 Jul 2013 11:02:32 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so4244394wiv.5 for ; Mon, 08 Jul 2013 11:02:31 -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=brNNqgUmIdyePiELr9PFQ5+LDntYC5Mt6tHYAzhlIcg=; b=nAuW1gOBjEiLLwbCdH2ASB1a3FTMt4BRWEluwC534x+AzPvkf8ziDDjP/hzwLSbkv/ Bazz7JCmoY1klns1+WP/sbmMq58KMXzzjf9+kSXZtX8DbrEOoy1sVz+Vh5rmP2vZW38B tqOE2CNCxDSwuzmWcus3QFYSsUw702knMYUsNhbwuSAA7hcIahqua2ghio/BRSSRARWO yb3yxbdHmsrsSmZQ6JNHEfMlQV3FV/OFfVJOwQTlNO/5dK3RV6L9xuTxg3kVf5V1SWOM cbt+FjBSugNxDplvIvYD6wN12bfEqIXHfiAW7zkY9ecAQJv+rQX83/zEj0Ymw8zawDhc 3+EA== 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=brNNqgUmIdyePiELr9PFQ5+LDntYC5Mt6tHYAzhlIcg=; b=Zr7FIkySnBX32yrrnoTFwvmbLFcSwBXeO9pLgoIpVj/9B8HrH6cJn3ErTmbVA3iQ+U DCZ8xlHhxcFOaA+riE9YHvaaNr/qTYzyCMWz6KFzMK/G9BpFsz/O+meYzBbGU9f6cGnp sDEgP6D1Sl3yIaJMuyIqlsItAyVb20EJ5CBTwKD4FfW/pQlzJybo8xlT0WMC0isIUEDR 6RzrS5xp43qt7NGnw5HaSsI+lpdXE2xGsVdeaJhjt1IrtqL1Ck0cSFof83Qnuykl48is Mbkh5KwAluZDAXgXDdvrGi4IyKZwg9B5gCQ7efftuPvb+8YdDyvbO5+yUYpLKQrV+2Cd oTgQ== X-Received: by 10.180.96.227 with SMTP id dv3mr12417131wib.59.1373306551024; Mon, 08 Jul 2013 11:02:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Mon, 8 Jul 2013 11:02:10 -0700 (PDT) In-Reply-To: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DAAF4B.4070004@viagenie.ca> From: Justin Uberti Date: Mon, 8 Jul 2013 14:02:10 -0400 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d0442727024671104e103d91d X-Gm-Message-State: ALoCoQn0cdNafcH+l5uWphoxSQu94MOCFOX4kp91xC3pzDIbk74qLEzxSUt1/O+zbbYOvyNTqZoANYJg4X0b/xyhoqU1JPZVqquCY+AjhRpb4Zfr7MKn5l1IRGWxMKn/8atij6vMnsxdVLiTULRZP3oxX6tV9DMINBOhcTYAp71hedyNDSEhtuFc14dlGWZPsmgtuemY2m2p Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:02:33 -0000 --f46d0442727024671104e103d91d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 8, 2013 at 12:48 PM, Martin Thomson w= rote: > Two separate replies... > > On 8 July 2013 05:23, Simon Perreault wrote= : > > Le 2013-07-08 06:24, Justin Uberti a =C3=A9crit : > >> Just uploaded a 00 version of a spec for requesting time-limited TURN > >> credentials for WebRTC apps. Would like to get 10 minutes of agenda ti= me > >> to present this in Berlin. > > Justin, is this the right working group for this draft? Presumably, > you want to talk to whoever owns TURN, which is (I believe) behave. > WebRTC applications are the primary beneficiaries of this proposal, which is why I submitted it here. I can certainly send it to BEHAVE if that's a better fit. (Depending on how closely this references draft-reddy-behave-turn-auth, that might be a good indication of where this should end up.) > > > One small comment: shouldn't the response also contain the value of the > > REALM parameter? > > I assume that this is intended to use the short term credential > mechanism. No need to use long term credentials in this case. > RFC 5766 mandates the use of the long-term credential mechanism. One of the goals of this proposal is to work with existing TURN servers, so it also uses the long-term credential mechanism, the key point being that the vended credentials have finite lifetimes. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d0442727024671104e103d91d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 8, 2013 at 12:48 PM, Martin Thomson &= lt;martin.tho= mson@gmail.com> wrote:
Two separate replies...

On 8 July 2013 05:23, Simon Perreault <simon.perreault@viagenie.ca> wrote:
> Le 2013-07-08 06:24, Justin Uberti a =C3=A9crit :
>> Just uploaded a 00 version of a spec for requesting time-limited T= URN
>> credentials for WebRTC apps. Would like to get 10 minutes of agend= a time
>> to present this in Berlin.

Justin, is this the right working group for this draft? =C2=A0Presuma= bly,
you want to talk to whoever owns TURN, which is (I believe) behave.

WebRTC applications are the primary beneficiar= ies of this proposal, which is why I submitted it here. I can certainly sen= d it to BEHAVE if that's a better fit. (Depending on how closely this r= eferences draft-reddy-behave-turn-auth, that might be a good indication of = where this should end up.)

> One small comment: shouldn't the response also contain the value o= f the
> REALM parameter?

I assume that this is intended to use the short term credential
mechanism. =C2=A0No need to use long term credentials in this case.

RFC 5766 mandates the use of the long-term cre= dential mechanism. One of the goals of this proposal is to work with existi= ng TURN servers, so it also uses the long-term credential mechanism, the ke= y point being that the vended credentials have finite lifetimes.
=C2=A0
_________________________________________= ______
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--f46d0442727024671104e103d91d-- From juberti@google.com Mon Jul 8 11:12:52 2013 Return-Path: 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 6FD6221F9D02 for ; Mon, 8 Jul 2013 11:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.310, 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 Q8LfvafjOJLn for ; Mon, 8 Jul 2013 11:12:47 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 58E6821F9BC8 for ; Mon, 8 Jul 2013 11:12:43 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so4007502wes.15 for ; Mon, 08 Jul 2013 11:12:41 -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=L0tWZy7iXiK3kSZ589lospaPD6HkZgaXwwvNFVAWErM=; b=K7SNpV23uQ6aByxazZQOSaMokUFGyMIgZMl0zN3CHHT7fEuywsQ0Rs039ZQJx4YAsL UupNcKSfn232yoQyp+zli16AAbbf8xQRfJDXfKLOuQtChkA9iawz6kcBzsB1FkRaaGSu GE2W2xMvRXJWrRYTe+Px1NwRonwU80NmB+YCqGkalVGJHHG064oSrRKCbnc14pP9/1Tn zHg3GdzGZsF5wKAfmUBVd9HYdW9U/hbDWmTVTd3Q82MD5Z+dWNF1xYH5s244DIr1Iz7f z6gifW9HNTOOE+abIEBhkvaq1A3c0l0lQrQjRf8zudl79vbZ3E4QB5oRfkN16mtonYQO FydA== 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=L0tWZy7iXiK3kSZ589lospaPD6HkZgaXwwvNFVAWErM=; b=MEQo/kOY+FP9KKwCkKlPQoX8oIBNLGJPBOi1ifAQa6rnY1On/aEsOYqOVCP2nfjN0a kf5O2/IaLlI6ItlqE01nKhE49ZDAeQAysYKAXML9Gjqpm5ghNKchTmPCHs19NYVLxlLL ZhG4pSPmjR2g3jhtTZgd0hu4lrNTs+Fsnlqa+yGh62lt4XFGDPB8gCua7JchVAF7eEW2 HiwuoCVtoLzJ9ep9A0dG2wrjtDS5ZF1M4WDrGQQZyOuj8hD60KVpl9acn4UmrE9tyZeS p5YeNpOUi0sYOtXOrNYDjVu+enwMYILrkr4Lq6e13z7yVIpB1pf6bnho54eKs+O8hc1Z HDCw== X-Received: by 10.194.58.239 with SMTP id u15mr12866031wjq.87.1373307161399; Mon, 08 Jul 2013 11:12:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Mon, 8 Jul 2013 11:12:21 -0700 (PDT) In-Reply-To: <51DAAF4B.4070004@viagenie.ca> References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DAAF4B.4070004@viagenie.ca> From: Justin Uberti Date: Mon, 8 Jul 2013 14:12:21 -0400 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7ba97b9485f1a704e103fd2d X-Gm-Message-State: ALoCoQnjUm4nr1DG9M9QOAdsJUQ6FY01xpTcmbh3QEXH4C8RT9Pd8/IvVT0ciVZb1lD5SjC243pwFBZKtbhB8MWqGjkk/gAwTw9qM7chpHuaIMKgK3R1zdCByYbsOCZbYSnvs/j0KqMbMgI28TkT04QZr9iOj7hmFP70DQYHkbGzqcU072TQ5Xq2ETQDxzV56EWUEMlsN07I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:12:52 -0000 --047d7ba97b9485f1a704e103fd2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 8, 2013 at 8:23 AM, Simon Perreault wrote: > Le 2013-07-08 06:24, Justin Uberti a =C3=A9crit : > > Just uploaded a 00 version of a spec for requesting time-limited TURN > > credentials for WebRTC apps. Would like to get 10 minutes of agenda tim= e > > to present this in Berlin. > > Cool. > > One small comment: shouldn't the response also contain the value of the > REALM parameter? > It could carry the REALM parameter, but if so, it would only be used to verify the REALM that was supplied by the server as part of the ALLOCATE challenge. Did you have something else in mind? --047d7ba97b9485f1a704e103fd2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 8, 2013 at 8:23 AM, Simon Perreault &= lt;simon.p= erreault@viagenie.ca> wrote:
Le 2013-07-08 06:24, Justin Uberti a =C3=A9c= rit :
> Just uploaded a 00 version of a spec for requesting = time-limited TURN
> credentials for WebRTC apps. Would like to get 10 minutes of agenda ti= me
> to present this in Berlin.

Cool.

One small comment: shouldn't the response also contain the value of the=
REALM parameter?

It could carry the REA= LM parameter, but if so, it would only be used to verify the REALM that was= supplied by the server as part of the ALLOCATE challenge. Did you have som= ething else in mind?
--047d7ba97b9485f1a704e103fd2d-- From juberti@google.com Mon Jul 8 11:16:18 2013 Return-Path: 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 8C9B221F9CBD for ; Mon, 8 Jul 2013 11:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.207, 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 13yqpw-r5t-B for ; Mon, 8 Jul 2013 11:16:17 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4728821F9A18 for ; Mon, 8 Jul 2013 11:16:17 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so9335317wiv.1 for ; Mon, 08 Jul 2013 11:16:15 -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=5pP5wWDxIFQKQtYe0fuLGis9lllqTvNyyEhEO/jwCGo=; b=JOCa59bh16kipdn3IGhHbhb3wywVWSZ3oBbFmF/majCdeRqzpLY1icTsxkaRCju2nj 87aVWJ6ROgaDp7jeHRBQ8PEqxig1WgxeipM3ObYA3/3S2hDunQPn1TXodCMRva9YX3Ef xMoV+cQLYI1bTlfr49+o+9I/xJeN5Kz0kJ5aZ5QnSiaEx0ytELh3X+zGu58O4yvgUrTY P5b8/2Ij0yd8CM5cWb3xfsyU0kUTqbIdeZQjETBMEQx2F6zi2f/j5+uhO5opmMyrtFOJ Ssu3gW/nOEtVxe1J2XtgvNnX2JHohUiyzXwyGH1l73qgKVdCFC7eTt5e/bEcsfhzMPYX PwqQ== 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=5pP5wWDxIFQKQtYe0fuLGis9lllqTvNyyEhEO/jwCGo=; b=nOKY9qW9/y6puTLw7+iSEuVgymJ6iT4Tj/0+QSB9kUusLmYoWU2Pu+xuALBXUfFRuM cK2gRZcoHobItcrMPtqdUf+i2d8Lf7u3KAygFcqLgoMuWgerPOKEUru114HjtMJR+Z6f aH8wxEw8ZJnUmpjQthWR860AYCtUJECn70aOE1Qtb+9YoYCiTPXgdiDfSoY4VpvIf0Gd Mj2JTuXtULgCSGGBvW3rQbN2vrIVpa/MQVCLHIoKiYba/3F5Z1v6T8w9M76ZQjy590Hq 5/1Lhpv4GAfRw4QtVqQAcpH4BpYG80i+7qfxYkTgRSG2tnNWG5GxwQ5oXBd+GcOTq9vo uSXQ== X-Received: by 10.180.96.227 with SMTP id dv3mr12444198wib.59.1373307375090; Mon, 08 Jul 2013 11:16:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Mon, 8 Jul 2013 11:15:55 -0700 (PDT) In-Reply-To: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Mon, 8 Jul 2013 14:15:55 -0400 Message-ID: To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=f46d0442727042a0ed04e1040afa X-Gm-Message-State: ALoCoQmHvi3E8dh76QV3CQVEMxQHADr5A9orm7t67BY/zvUouaua8VA0eHfS9ZoePhTZR5xJRlLnDWmhvj3ruIxXWm5SOWxfSa0rIJhq78Cy3CSTK0pl+CFjV3Z0GTVc31ZSTFvF3jziRTWZzHx3NvGFQWuKP9S08n5tjzyZEiJqOufmGugl8l4AguJ5+lyzrNUd6urKR+JI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:16:18 -0000 --f46d0442727042a0ed04e1040afa Content-Type: text/plain; charset=UTF-8 On Mon, Jul 8, 2013 at 1:52 AM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > Hi Justin,**** > > ** ** > > A few quick comments:**** > > 1) The primary advantage of the proposed mechanism seems not requiring any > interaction between the web service and the TURN service in order for the > TURN service to grant TURN credentials in the HTTP response -- this absence > of interaction isn't evident on a first read. A diagram showing the client, > web service, TURN service and the messages exchanged would be helpful. > This is mentioned in the introduction, but agree a diagram would be helpful. > **** > > ** ** > > 2) **** > > |If desired, the TURN server can optionally verify that the parsed**** > > |user id value corresponds to a currently valid user of an external**** > > |service (e.g. is currently logged in to the web app that is making**** > > |use of TURN). This requires proprietary communication between the**** > > |TURN server and external service on each ALLOCATE request, so this**** > > |usage is not recommended for typical applications. If this external**** > > |verification fails, it SHOULD reject the request with a 401**** > > |(Unauthorized) error.**** > > ** ** > > Was the intention of putting "not recommended" having a normative > statement? If not, it would be better to change it to "no needed". > I was waffling on this - I think I will just make it "not needed", and leave this decision up to the implementor. > **** > > ** ** > > 3) There is no text describing how the timestamp encoded in the UNSERNAME > attribute of the ALLOCAE requested could be protected. > In the HTTP Interactions section, I mention that the password used for the MESSAGE-INTEGRITY is a digest of the username, but I can make this more explicit. > **** > > ** ** > > 4) draft-reddy-behave-turn-auth describes the issues with TURN > authentication and draft-uberti-rtcweb-turn-rest looks like one possible > solution. Looks both could reference each other. > Agreed - hadn't seen that draft before since it wasn't in rtcweb. > **** > > ** ** > > Muthu**** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* Monday, July 08, 2013 9:55 AM > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] Fwd: New Version Notification for > draft-uberti-rtcweb-turn-rest-00.txt**** > > ** ** > > Just uploaded a 00 version of a spec for requesting time-limited TURN > credentials for WebRTC apps. Would like to get 10 minutes of agenda time to > present this in Berlin.**** > > ** ** > > ---------- Forwarded message ---------- > From: > Date: Mon, Jul 8, 2013 at 12:15 AM > Subject: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt > To: Justin Uberti > > > > A new version of I-D, draft-uberti-rtcweb-turn-rest-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-rtcweb-turn-rest > Revision: 00 > Title: A REST API For Access To TURN Services > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-turn-rest-00.txt > Status: > http://datatracker.ietf.org/doc/draft-uberti-rtcweb-turn-rest > Htmlized: > http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00 > > > Abstract: > This document describes a proposed standard REST API for obtaining > access to TURN services via ephemeral (i.e. time-limited) > credentials. These credentials are vended by a web service over > HTTP, and then supplied to and checked by a TURN server using the > standard TURN protocol. The usage of ephemeral credentials ensures > that access to the TURN server can be controlled even if the > credentials can be discovered by the user, as is the case in WebRTC > where TURN credentials must be specified in Javascript. > > > > > The IETF Secretariat**** > > ** ** > > ** ** > --f46d0442727042a0ed04e1040afa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 8, 2013 at 1:52 AM, Muthu Arul Mozhi Perumal (mperumal)= <mperumal@cisco.com> wrote:

Hi Justin,

=C2=A0

A few quick comments:

1) The primary advantage of the proposed= mechanism seems not requiring any interaction between the web service and = the TURN service in order for the TURN service to grant TURN credentials in the HTTP response -- this absence of interaction isn&#= 39;t evident on a first read. A diagram showing the client, web service, TU= RN service and the messages exchanged would be helpful.


This is mentioned in the introductio= n, but agree a diagram would be helpful.=C2=A0

=C2=A0

2)

|If desired, the TURN server can optiona= lly verify that the parsed

|user id value corresponds to a currentl= y valid user of an external

|service (e.g. is currently logged in to= the web app that is making

|use of TURN).=C2=A0 This requires propr= ietary communication between the

|TURN server and external service on eac= h ALLOCATE request, so this

|usage is not recommended for typical ap= plications.=C2=A0 If this external

|verification fails, it SHOULD reject th= e request with a 401

|(Unauthorized) error.

=C2=A0

Was the intention of putting "not r= ecommended" having a normative statement? If not, it would be better t= o change it to "no needed".


I was waffling on this - I thi= nk I will just make it "not needed", and leave this decision up t= o the implementor.=C2=A0

=C2=A0

3) There is no text describing how the t= imestamp encoded in the UNSERNAME attribute of the ALLOCAE requested could = be protected.

=C2=A0
In the HTTP Interactions= section, I mention that the password used for the MESSAGE-INTEGRITY is a d= igest of the username, but I can make this more explicit.

=C2=A0

4) draft-reddy-behave-turn-auth describe= s the issues with TURN authentication and draft-uberti-rtcweb-turn-rest loo= ks like one possible solution. Looks both could reference each other.


Agreed = - hadn't seen that draft before since it wasn't in rtcweb.=C2=A0

=C2=A0

Muthu

=C2=A0

From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Monday, July 08, 2013 9:55 AM
To: rtcweb@ietf= .org
Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtc= web-turn-rest-00.txt

=C2=A0

Just uploaded a 00 version of a spec for requesting = time-limited TURN credentials for WebRTC apps. Would like to get 10 minutes= of agenda time to present this in Berlin.

=C2=A0

---------- Forwarded = message ----------
From: <int= ernet-drafts@ietf.org>
Date: Mon, Jul 8, 2013 at 12:15 AM
Subject: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt<= br> To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-rtcweb-turn-rest-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-uberti-rtcweb-turn-rest
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A REST API For Access To TURN Ser= vices
Creation date: =C2=A0 2013-07-08
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 7
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-turn-rest-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatrack= er.ietf.org/doc/draft-uberti-rtcweb-turn-rest
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h= tml/draft-uberti-rtcweb-turn-rest-00


Abstract:
=C2=A0 =C2=A0This document describes a proposed standard REST API for obtai= ning
=C2=A0 =C2=A0access to TURN services via ephemeral (i.e. time-limited)
=C2=A0 =C2=A0credentials. =C2=A0These credentials are vended by a web servi= ce over
=C2=A0 =C2=A0HTTP, and then supplied to and checked by a TURN server using = the
=C2=A0 =C2=A0standard TURN protocol. =C2=A0The usage of ephemeral credentia= ls ensures
=C2=A0 =C2=A0that access to the TURN server can be controlled even if the =C2=A0 =C2=A0credentials can be discovered by the user, as is the case in W= ebRTC
=C2=A0 =C2=A0where TURN credentials must be specified in Javascript.




The IETF Secretariat

=C2=A0

=C2=A0


--f46d0442727042a0ed04e1040afa-- From martin.thomson@gmail.com Mon Jul 8 11:16:33 2013 Return-Path: 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 2CDC721F9D72 for ; Mon, 8 Jul 2013 11:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, 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 xVz1IIACf0jd for ; Mon, 8 Jul 2013 11:16:32 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0C821F9CF1 for ; Mon, 8 Jul 2013 11:16:32 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k14so3966468wgh.17 for ; Mon, 08 Jul 2013 11:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zYESjbtINnHldVR47BTzNC9qo0ZgicM+oW3TIbQZNe4=; b=iYuh/8eYyw2UwN3UuqcecHeXUD8bacmVlRovX3ator84Qa0Ve7/wt0YovF/d4oK0LK GulKvs5UDsouLgu7OOcCKqruMXu/L0QKyHvTa0biBNk92A1YS07CuzpD+rPH3IDH1QSd XIk+xR9CsvQOUnem3BhnCZgeu8bgXnn3v8bp1f3hHrrZ0RYeeVAhOTLDC1rNTjWi/XqM XEiDf9GwG9S9/CB5MJwe6n6KyualbyeRIBzZ8TvGfjT5bC4ZBruDCGuT6VK/+VDY46Rv aeYu/RC2J502vd6cbqjUDkAAwFhFol9oibH7Kwq7C7VJImAGUxBMEtru7yVHQgrbW8ID Ynmg== MIME-Version: 1.0 X-Received: by 10.180.9.212 with SMTP id c20mr29764316wib.65.1373307391556; Mon, 08 Jul 2013 11:16:31 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 8 Jul 2013 11:16:31 -0700 (PDT) In-Reply-To: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DAAF4B.4070004@viagenie.ca> Date: Mon, 8 Jul 2013 11:16:31 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:16:33 -0000 On 8 July 2013 11:02, Justin Uberti wrote: > RFC 5766 mandates the use of the long-term credential mechanism. One of the > goals of this proposal is to work with existing TURN servers, so it also > uses the long-term credential mechanism, the key point being that the vended > credentials have finite lifetimes. You could update 5766 to remove this constraint (I forgot about that bit)...and the extra round trip required for the challenge. Or you could provide the client with a realm and nonce in the response, but that seems like a little too much. From simon.perreault@viagenie.ca Mon Jul 8 11:41:25 2013 Return-Path: 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 8D8F621F9D17 for ; Mon, 8 Jul 2013 11:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, 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 kIFSP0Qn8bKR for ; Mon, 8 Jul 2013 11:41:24 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 569C821F9C0C for ; Mon, 8 Jul 2013 11:41:24 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 83AFE40062; Mon, 8 Jul 2013 14:41:23 -0400 (EDT) Message-ID: <51DB07D2.60100@viagenie.ca> Date: Mon, 08 Jul 2013 20:41:22 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Justin Uberti References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DAAF4B.4070004@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:41:25 -0000 Le 2013-07-08 20:12, Justin Uberti a écrit : > One small comment: shouldn't the response also contain the value of the > REALM parameter? > > > It could carry the REALM parameter, but if so, it would only be used to > verify the REALM that was supplied by the server as part of the ALLOCATE > challenge. Did you have something else in mind? Either that or the text needs to say that the REALM sent by the server is to be ignored by the client. I have no opinion at this point, really, other than the text needs to say something about REALM. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From juberti@google.com Mon Jul 8 13:09:31 2013 Return-Path: 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 57A2121F9D83 for ; Mon, 8 Jul 2013 13:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 RCs5edC1AZ5g for ; Mon, 8 Jul 2013 13:09:30 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29921F9B5C for ; Mon, 8 Jul 2013 13:09:20 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so4095784wes.31 for ; Mon, 08 Jul 2013 13:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5FX7BNljhbf+rerzJLBX0ZtibZvO+H3jgtM8L8PSuVg=; b=KkTOsstCyFVVf/yZFyRU58nIefR7BZa6lXRg0WO62ZD/oeO/N0RrXmftsjEJpvLsJL RRg+p/Q2cK+jPmD4+xeGJ21cWoSn0ZTlUHd4TzQQ01ZmN2drwy31kPaTYQ8YLIjmbRYg QPSzUlVu+pa6ql3eMOHzMIeemFg1mJudgBg29DONHr+VrG90H/xYX0Dgpyypen57Gviq 5r+LiN1JQ3V8iZXGwleB1STb8XNpcGympDwTKQe7WIp0hVS2RMBfMsthyh+jscjLLGLF UWCiRNh0+GwUXCB/uxPO9SH3WpO8qyos3iYiBLcWLbtlis0Dq32jOUKKtvAvP+LQb9P/ dIGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=5FX7BNljhbf+rerzJLBX0ZtibZvO+H3jgtM8L8PSuVg=; b=VVVm2/eTgfpoPopHt8VJa0Ux94eDqXuNhROR98aiKw650bQanC2wjFd58A0+6nUDVy NB3KMp6FR2WsIoc6GwuohpfIikiDTObQLUXFezwlhRQzTmX/S2eTfDurLC4ElIM+Y9xD wpEPV4tuOOR5klATX/WjL/YNyKnNbg4GZHsQ5D8ZSTeRYtPgDB4Gptotf7UECYJX0jhA bB14JX5NmsY30Iu+wNsd+0ha3XeQayugj/0/JC+lkuoMPjtMEPZU26wZe4QZNTHVHV3Y trz+uQlJ8KqRpsZoAYMtoxx3PPhYgUD4OpWUfa0BuKaPlnJYkIK4wMRDT1ZvIOjSi3CK zAwg== MIME-Version: 1.0 X-Received: by 10.180.80.6 with SMTP id n6mr30587907wix.59.1373314160161; Mon, 08 Jul 2013 13:09:20 -0700 (PDT) Received: by 10.194.62.113 with HTTP; Mon, 8 Jul 2013 13:09:20 -0700 (PDT) Received: by 10.194.62.113 with HTTP; Mon, 8 Jul 2013 13:09:20 -0700 (PDT) In-Reply-To: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DAAF4B.4070004@viagenie.ca> Date: Mon, 8 Jul 2013 16:09:20 -0400 Message-ID: From: Justin Uberti To: Martin Thomson Content-Type: multipart/alternative; boundary=14dae9cc955cae97c704e1059e72 X-Gm-Message-State: ALoCoQmbdml0pHoFMSigrTu2FB9gy7Vr1kSceWJkEN/JF2xxfZuVViQ7FGyT+hQiSmupwL/HyoqK9pOJzujSnkrsloCe1/QhUqaGPH9Mr+aJVzSxnwj/xMdHcfLE5eHw/uxI8rAbASDeLXdJfs8D8XErLGTjfSLPinuPxT+wfjy9v3IyP3YEX+IefY35pO18PHiw5KBEYE5c Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:09:31 -0000 --14dae9cc955cae97c704e1059e72 Content-Type: text/plain; charset=UTF-8 On Jul 8, 2013 2:16 PM, "Martin Thomson" wrote: > > On 8 July 2013 11:02, Justin Uberti wrote: > > RFC 5766 mandates the use of the long-term credential mechanism. One of the > > goals of this proposal is to work with existing TURN servers, so it also > > uses the long-term credential mechanism, the key point being that the vended > > credentials have finite lifetimes. > > You could update 5766 to remove this constraint (I forgot about that > bit)...and the extra round trip required for the challenge. > > Or you could provide the client with a realm and nonce in the > response, but that seems like a little too much. The issue with using short term credentials, without a nonce, is the possibility of replay attacks by an eavesdropper. Passing realm and nonce solves this but is problematic because nonces need to be per-allocation, so you'd need some sort of master nonce that could be used for nonce generation. Plus the Rtciceserver API would need to be expanded. --14dae9cc955cae97c704e1059e72 Content-Type: text/html; charset=UTF-8


On Jul 8, 2013 2:16 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> On 8 July 2013 11:02, Justin Uberti <juberti@google.com> wrote:
> > RFC 5766 mandates the use of the long-term credential mechanism. One of the
> > goals of this proposal is to work with existing TURN servers, so it also
> > uses the long-term credential mechanism, the key point being that the vended
> > credentials have finite lifetimes.
>
> You could update 5766 to remove this constraint (I forgot about that
> bit)...and the extra round trip required for the challenge.
>
> Or you could provide the client with a realm and nonce in the
> response, but that seems like a little too much.

The issue with using short term credentials, without a nonce, is the possibility of replay attacks by an eavesdropper.

Passing realm and nonce solves this but is problematic because nonces need to be per-allocation, so you'd need some sort of master nonce that could be used for nonce generation. Plus the Rtciceserver API would need to be expanded.

--14dae9cc955cae97c704e1059e72-- From stefan.lk.hakansson@ericsson.com Mon Jul 8 13:34:15 2013 Return-Path: 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 D22B121F9DAD for ; Mon, 8 Jul 2013 13:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.241 X-Spam-Level: X-Spam-Status: No, score=-5.241 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 IKElcbLppn8X for ; Mon, 8 Jul 2013 13:34:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F10EE21F9D7C for ; Mon, 8 Jul 2013 13:34:09 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-d2-51db22407782 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DB.6C.05990.0422BD15; Mon, 8 Jul 2013 22:34:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Mon, 8 Jul 2013 22:34:07 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Peter Thatcher Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOeDFbTNRhHYI3NkSZeqhrbqmeQg== Date: Mon, 8 Jul 2013 20:34:06 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30CD09@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvra6D0u1Ag8apchbXlr9mtZhxYSqz xdp/7ewOzB4LNpV6LFnyk8nj1pSCAOYoLpuU1JzMstQifbsErowre7azFfyyqfjZ2MncwHhR r4uRk0NCwETi6tXrjBC2mMSFe+vZuhi5OIQEDjNK/Nq8kAnCWcgocfrfOWaQKjaBQImt+xaw gdgiApoSkyc3s3YxcnAwC/hIzN2sCBIWFqiSWH74GDtIWESgWmJJfzlEtZ5E18WtLCBhFgEV iQObE0DCvAK+EvveLWABsYUEdrNI7P2rD2IzAp3z/dQaJhCbWUBc4taT+UwQZwpILNlznhnC FpV4+fgfK4StJPFjwyUWiHo9iRtTp7BB2NoSyxa+ZobYJShxcuYTlgmMorOQjJ2FpGUWkpZZ SFoWMLKsYmTPTczMSS832sQIjIuDW36r7mC8c07kEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF 8UWlOanFhxiZODilGhgNV6p7H/8RMCfu8tObHNl3S6b4X1hRohIaJ9ht1dtwz3iHoSWPaN86 94cPtkn88pLc9WfejpK7S9lLZjEmlXw6M+3o1mtqLyUvRhftSz6soHW+dsarM4HcN/7G1kss 9vAScDNff62jxLHw2rv6+QLydVbM+4wZd6tMEVvP/TXJe937JzZ6IclKLMUZiYZazEXFiQC1 GOmoWQIAAA== Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:34:15 -0000 On 7/8/13 4:38 PM, Peter Thatcher wrote:=0A= >=0A= >=0A= >=0A= > On Mon, Jul 8, 2013 at 5:11 AM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > On 7/7/13 11:14 PM, Roman Shpount wrote:=0A= > >=0A= > > On Sat, Jul 6, 2013 at 2:33 AM, Stefan H=E5kansson LK=0A= > > =0A= > > >> wrote:=0A= > >=0A= > > On 7/3/13 11:37 PM, Eric Rescorla wrote:=0A= > > > I'm glad to be wrong here. Is the phrase "you=0A= > shouldn't have to=0A= > > > modify the SDP but rather there should be API points=0A= > to cover=0A= > > most=0A= > > > of the use cases" the consensus of the working group?= =0A= > > >=0A= > > >=0A= > > > I thought it was, but I'm not the chair, so maybe you=0A= > could ask=0A= > > Harald or=0A= > > > Stefan.=0A= > >=0A= > > I definitely think this is the consensus of the working group.= =0A= > >=0A= > >=0A= > > Can you point out when exactly this consensus was reached? This=0A= > is news=0A= > > to me, but I definitely could have missed something.=0A= >=0A= > No I can't really. To be clear, no consensus call (or similar) has be= en=0A= > held. But every time this is discussed, what I hear is people agreein= g=0A= > and no objections. It was discussed a bit, e.g., at the f2f at TPAC= =0A= > last=0A= >=0A= > year, if you read the minutes [1] you will find some traces of that= =0A= > discussion.=0A= >=0A= >=0A= > No objections at all? That is rather surprising to me. I asked for=0A= > some feedback the API in the spreadsheet from web developers, at there=0A= > many objections from them about this part of the API. A majority did=0A= > say it was good enough for simple use cases, but he objections were=0A= > still clearly non-zero.=0A= =0A= I think we're discussing different things. I'm referring to adding API =0A= methods that would allow meeting most use-cases without SDP mangling - =0A= under the presumption that SDP O/A would be used as part of the design. =0A= And that is what we have been assuming, and the WebRTC WG confirmed this = =0A= last year when it was up for discussion.=0A= =0A= What I see being most discussed now is the role of SDP O/A - not that it = =0A= would not be helpful to have API methods that allowed meeting use-cases =0A= without SDP mangling if SDP O/A stays.=0A= =0A= >=0A= > I think perhaps the web developers are not well represented at TPAC.=0A= > But I could be wrong. Perhaps they are but changed their mind. Or=0A= > maybe they're objecting on the IETF mailing list when they should object= =0A= > on the IETF mailing list. Or maybe the spreadsheet has a sample bias,= =0A= > while TPAC is the true sample. I don't know, but it seems like=0A= > something is going on, and I'd like to know what it is.=0A= >=0A= > Stefan, what do you think? What could explain the apparent=0A= > contradiction between objections on the mailing list vs. no objections f2= f?=0A= =0A= Again, I think that we are to some extent discussing different things =0A= (see above).=0A= =0A= But I can only speculate. There is not a 100% overlap between people who = =0A= have raised concerns on the rtcweb list and the people usually active in = =0A= the W3C WebRTC WG, this can be a reason.=0A= =0A= >=0A= >=0A= > Also, on discussions about the API, should those who want to propose=0A= > additions (such as the NoPlan JS API I proposed) and other comments put= =0A= > them on the W3C mailing list instead of the IETF one? Is everyone=0A= > barking up the wrong tree?=0A= =0A= I think API proposals should be taken to the W3C list.=0A= =0A= >=0A= > Thanks in advance for your input.=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > And, I don't understand why there would be a debate about this. There= =0A= > are obviously many who want to define APIs (or constraints) that allo= w=0A= > most use-cases to be met without having to modify the SDP. Why would= =0A= >=0A= > anyone have anything against that?=0A= >=0A= >=0A= > I think your question actually has two questions:=0A= >=0A= > 1. Is anyone against making additions to the API to avoid SDP munging?= =0A= >=0A= > 2. Why are they against additions to the API to avoid SDP munging?=0A= >=0A= >=0A= > My personal experience for #1 is that there are some notable people in=0A= > the WG who are very much against making additions to the API to avoid=0A= > SDP munging. Some of them are rather upset with me for proposing a few= =0A= > minor additions to the API (the NoPlan JS API) precisely because it=0A= > allows the JS to go around the SDP in many cases, and they don't like=0A= > that. So, from my experience, it's clear that the answer to #1 is "yes,= =0A= > many do".=0A= =0A= Just to be clear, what I meant in my comment was APIs that made the =0A= browser create an SDP that is suitable for the use-case at hand, not an =0A= API to go around SDP.=0A= =0A= >=0A= > And since many object to such additions, and others want such additions,= =0A= > you end up with debate.=0A= >=0A= >=0A= > How about #2? Why do they object? My experience is that they view any= =0A= > additions as a threat to API as a threat to the current API, which means= =0A= > it's a threat to the current WG progress, which means it's a threat to=0A= > getting done. They are very sensitive to such threats, and so object to= =0A= > any additions or changes that would allow JS to avoid using SDP.=0A= =0A= I must admit I am personally also a bit afraid of WG progress if we =0A= change too much. If your proposed API addition would be "too much" is =0A= another question.=0A= =0A= > Also,=0A= > I think they don't want to ways of doing things, so SDP must remain the= =0A= > one true way.=0A= >=0A= >=0A= > But that's just my personal experience and perspective. I could just be= =0A= > seeing it wrong, or maybe the only person experiencing this.=0A= >=0A= >=0A= >=0A= >=0A= > I If there is anyone who really wants=0A= > to modify the SDP instead (I have no clue why, but anyway) they can= =0A= > still do that.=0A= >=0A= >=0A= > Well, no one is going to hit themselves in the head with a hammer if=0A= > they don't have to, but there are many uses cases that currently be done= =0A= > only by SDP munging, and I don't see any API additions on the horizon=0A= > that will help those uses cases. So, until we can agree on some API=0A= > additions that help SDP munging, many web developers are going to have=0A= > to keep swinging that hammer, no matter how much it hurts.=0A= =0A= I think I need to do some reading up because the info must all be there =0A= among all the mails, but it would really be helpful to have a list of =0A= things people would like to do, and that currently require SDP mangling.=0A= =0A= >=0A= > But clearly, if you gave them an API that didn't require such pain, they= =0A= > would use it.=0A= >=0A= >=0A= > [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Nov/0072.ht= ml=0A= >=0A= > > _____________=0A= > > Roman Shpount=0A= > >=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= >=0A= =0A= From stefan.lk.hakansson@ericsson.com Mon Jul 8 13:37:11 2013 Return-Path: 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 80A8821F9D7C for ; Mon, 8 Jul 2013 13:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.295 X-Spam-Level: X-Spam-Status: No, score=-5.295 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 tTehHJ3jm76b for ; Mon, 8 Jul 2013 13:37:05 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C214321F9C2D for ; Mon, 8 Jul 2013 13:37:04 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-68-51db22eee593 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 13.74.19388.EE22BD15; Mon, 8 Jul 2013 22:37:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Mon, 8 Jul 2013 22:37:02 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Roman Shpount Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOeDFbTNRhHYI3NkSZeqhrbqmeQg== Date: Mon, 8 Jul 2013 20:37:01 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvre47pduBBm8bFS1WvD7HbjHjwlRm i7X/2tkdmD2WLPnJ5DH5cRuzx60pBQHMUVw2Kak5mWWpRfp2CVwZj9atZitYzFSxY8YK9gbG l4xdjJwcEgImEq+Xr2KHsMUkLtxbz9bFyMUhJHCYUeLmxt2MEM5CIGfRTFaQKjaBQImt+xaw gdgiAqoSf79PZgKxmQXcJXbduA1mCwtUSSw/fAxoKgdQTbXEkv5yiHI9ia6LW1lAbBYBFYm3 PafAjuAV8JXY1PcVavFuFokp/4+CXcQIdNH3U2ug5otL3HoynwniUgGJJXvOM0PYohIvH/9j hbCVJH5suMQCUa8ncWPqFDYIW1ti2cLXzBDLBCVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZV jOy5iZk56eXmmxiB8XFwy2+DHYyb7osdYpTmYFES592sdyZQSCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA+MqS+/OimK2k0s2fNyktfRhXKqni2nKz4BTt//7nv2tzaDy+M76IKtdPrHmR4LP 63xh1Fj3bKoO/5crmtt5Ppm8D1lV0SUu+mu9p+BOK4OJq3TdPig0XPzYKnziZMPW0i2Pjjbs un4/9EX+v5NJPJ5vdmhNnzNzx0XntMMLH/D8NE0uSXp6R6FbiaU4I9FQi7moOBEA+BN39l0C AAA= Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:37:11 -0000 On 7/8/13 5:22 PM, Roman Shpount wrote:=0A= =0A= > So, was there ever a consensus that "developers MUST NOT=0A= > touch SDP"?=0A= =0A= No, developers are free to touch the SDP (and probably must in certain =0A= cases).=0A= =0A= >=0A= > _____________=0A= > Roman Shpount=0A= =0A= From ibc@aliax.net Mon Jul 8 13:43:53 2013 Return-Path: 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 1A5D721F9E01 for ; Mon, 8 Jul 2013 13:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 fgmcaBywf7NW for ; Mon, 8 Jul 2013 13:43:47 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id C63EF21F9DF1 for ; Mon, 8 Jul 2013 13:43:47 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id b4so2612701qen.14 for ; Mon, 08 Jul 2013 13:43:46 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=+bwTFXUWiWBGXsIOQOktvrforTTQy/bQQ5k4IBnYe8I=; b=IOD3TttCWPqCfRhRNq5BczFXwXl2CrnMipsA8kEcgdgQVE9kolgWG0wONBq1dVAWpF xLELkyW7iNPBPspJKXF29Yqoqjl2odNqVLyZD29mQvSdRAOSSqLBLgOasoaiLIPj8ANF yIWHC9z8m7bFS6zU2lwvHS2tiptLgaZkMgPCZSrleRJMiPDbIjzTAKzZ+KG5bT8ml0wI QNZ58hcd5sxD8puf6MbHO71MW+AZcbHq+1a3po/K3rOqwv8DDktyzjsGWqll2x2h/0T3 51b1lShsQornkanG8aE7xX/pgrj0cKBVGsV0KA4wqCtdZz0oT9HEn8e9cC44s2lQCkRG E3eQ== X-Received: by 10.224.114.207 with SMTP id f15mr5457747qaq.115.1373316226721; Mon, 08 Jul 2013 13:43:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 8 Jul 2013 13:43:26 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Jul 2013 22:43:26 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnR3hg6+yQXNJaPSv/J7fi6SXtk+ZjraUiJ28OmEbTVB7YnIl+d5ZQK4bEid5C2+fc7Wc9x Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:43:53 -0000 2013/7/8 Stefan H=C3=A5kansson LK : >> So, was there ever a consensus that "developers MUST NOT >> touch SDP"? > > No, developers are free to touch the SDP (and probably must in certain > cases). Do you feel how much painful is "touching a browser generated SDP"? To be c= lear: - JS requests "A" to browser. - Browser returns "A" (in the form of unmanageable blob). - JS modifies "A" to send "A-bis" in the wire. - Remote peer receives "A-bis" and replies "B-bis". - Both JS app are lying to their respective browsers to get the desired behavior. This is really painful, really. In the other side, as I explained in other thread (may be in this one?) adding some methods to the current API (to avoid playing with the SDP) is not the way to go. A specification in which the JS app does not know what he is sending in-the-wire (a blob generated by the browser) is doomed to failure. Please remember that mandating SDP (plain SDP) means that no other media signaling protocol can be implemented in future WebRTC apps. SIP phones have *fixed* code and *fixed* logic. This is no longer true in the Web. -- I=C3=B1aki Baz Castillo From martin.thomson@gmail.com Mon Jul 8 14:43:38 2013 Return-Path: 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 4A9F321F9E45 for ; Mon, 8 Jul 2013 14:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 8pJExh0ozfPT for ; Mon, 8 Jul 2013 14:43:37 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA2C21F9E24 for ; Mon, 8 Jul 2013 14:43:37 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so9500504wiw.5 for ; Mon, 08 Jul 2013 14:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O3ht9iEuPelweko45dtCDtZLQmLuVhebDiONY+bpFuU=; b=NT6YsrDQzoKfocnHrYhV7clrBs8GbDZmTg6Hsf88Gz9wBXbHRP2b1a+g3+a4Z6OviL 5+P4kMP96yn/ygXQlt/QIt+tqeJISJko/HGgojbzKdbA8lejt8HXnLiBiwc8iOqKe3oO gorAxEEW737OpJhvELO4716xaAZSIm9rLgZWjoivDdZjYpQAAg/ztnv/yRJIxxAQdwCa DVKb6+gVhDbxcGd/rk1XQ80Z8PTc0aV4idERfyDH8HdSIQDasmsBpqMsFjXdsxaTyyNY WM80QekaR01uQjRjfDUbfvuvReGdttrXPONBEz8LviAbMU1dCX0FYxIkRUJJnXB8xUiu aXWQ== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr13385203wjx.84.1373319815337; Mon, 08 Jul 2013 14:43:35 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 8 Jul 2013 14:43:35 -0700 (PDT) In-Reply-To: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DAAF4B.4070004@viagenie.ca> Date: Mon, 8 Jul 2013 14:43:35 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:43:38 -0000 On 8 July 2013 13:09, Justin Uberti wrote: > The issue with using short term credentials, without a nonce, is the > possibility of replay attacks by an eavesdropper. It is no less vulnerable than having the long term credential set (username, nonce, realm, and password) overheard. Assuming that the lifetime of the password is the same in both cases. In either case, the link that the eavesdropper is required to attack is the HTTP link. > Passing realm and nonce solves this [...] I was suggesting that since you have spent some very expensive round-trips getting this information, there are no advantages in spending yet another round-trip on a challenge. I don't think that passing realm and nonce is a good idea in practice - it creates a tighter coupling between this new thing and the TURN server. In practice, a master nonce is not quite what you need, you need a nonce-generator function, or a line to the TURN server whereby you query for every request you get. The former imposes too-strong constraints on implementations, the latter renders much of the advantages of something like this moot. From adam@nostrum.com Mon Jul 8 14:51:10 2013 Return-Path: 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 9085321F9E4C for ; Mon, 8 Jul 2013 14:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 WTxBH0DMydnB for ; Mon, 8 Jul 2013 14:51:10 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A8E7A21F9CB8 for ; Mon, 8 Jul 2013 14:51:09 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r68Lp4FI003910 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 8 Jul 2013 16:51:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51DB3443.6070301@nostrum.com> Date: Mon, 08 Jul 2013 16:50:59 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Justin Uberti References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:51:10 -0000 On 7/7/13 23:24, Justin Uberti wrote: > Just uploaded a 00 version of a spec for requesting time-limited TURN > credentials for WebRTC apps. Would like to get 10 minutes of agenda > time to present this in Berlin. Thanks for getting ball rolling on this, Justin. I agree that this is an important mechanism to have defined. I only find one issue in my initial read through the document: why are we proposing the use of HTTP POST for stateless, idempotent information retrieval? The key benefit of this approach is that it doesn't actually create state in the network. That's a much better fit for GET. Compare RFC 2616, sections 9.3 and 9.5, and see if you don't agree. /a From martin.thomson@gmail.com Mon Jul 8 14:57:15 2013 Return-Path: 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 BF09021F9E3B for ; Mon, 8 Jul 2013 14:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, 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 mC1kvw5Jnl-B for ; Mon, 8 Jul 2013 14:57:14 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E11F921F9DED for ; Mon, 8 Jul 2013 14:57:10 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so4167884wev.14 for ; Mon, 08 Jul 2013 14:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J/qqY0CP4m+YO4eL9CCmnP9VqdFi2lWbfEpDspbb1OI=; b=TqxpJCb3NsvulN0O2fyus92zRZSuQ15/rDBtN7kDsgHoXoVbMayd/yHyn14F+eqzCZ /cj/6dWxneT2RVd9I10vkyF8ZSZmXfcS2EI1pbsfpKdkBr4kYmZAjAUSHoV0lQwYOjfb p+3XB+946oNcy4ZuBnE8S4v2qEBIKwPuQeeJMFhKEUnk2UXmt0FU9g8efN27ACjhSZ0l AqfPxEcXOyp3ECqdkNJE/UNIFCLfmidgscwi79BGM69im6r+DBM8TbBWUHRn7wHnv4wL TSv9shCFY3gq6yzWR0yYXZtvWxgEPqrjKAY9yRekC/BHeRJgKyPWtdD94b7b6EIt55sl BjaA== MIME-Version: 1.0 X-Received: by 10.194.77.99 with SMTP id r3mr13423494wjw.5.1373320629980; Mon, 08 Jul 2013 14:57:09 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 8 Jul 2013 14:57:09 -0700 (PDT) In-Reply-To: <51DB3443.6070301@nostrum.com> References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DB3443.6070301@nostrum.com> Date: Mon, 8 Jul 2013 14:57:09 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:57:15 -0000 On 8 July 2013 14:50, Adam Roach wrote: > I only find one issue in my initial read through the document: why are we > proposing the use of HTTP POST for stateless, idempotent information > retrieval? The key benefit of this approach is that it doesn't actually > create state in the network. That's a much better fit for GET. That's an interesting question. From one perspective, this is not idempotent, nor is it safe. It creates a new resource: a new username/password pair with a defined validity. You could even identify this "resource" with a URI. Imagine what a DELETE on that resource would do... But it's equally valid to try to pretend otherwise and use GET. After all, most servers won't actually be allocating any state for these things. And I can't think of an actual, practical use for DELETE, so that's just a silly feature. --Martin p.s., I was going to let this slide, but this design is not RESTful, no sense in pretending like it is. From adam@nostrum.com Mon Jul 8 15:06:17 2013 Return-Path: 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 22E1221F9AEF for ; Mon, 8 Jul 2013 15:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 tY6NIrecCuyU for ; Mon, 8 Jul 2013 15:06:16 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 65C6021F9CCE for ; Mon, 8 Jul 2013 15:06:15 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r68M626m005520 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 8 Jul 2013 17:06:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51DB37C5.3060701@nostrum.com> Date: Mon, 08 Jul 2013 17:05:57 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Martin Thomson References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DB3443.6070301@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 22:06:17 -0000 On 7/8/13 16:57, Martin Thomson wrote: > On 8 July 2013 14:50, Adam Roach wrote: >> I only find one issue in my initial read through the document: why are we >> proposing the use of HTTP POST for stateless, idempotent information >> retrieval? The key benefit of this approach is that it doesn't actually >> create state in the network. That's a much better fit for GET. > That's an interesting question. From one perspective, this is not > idempotent, nor is it safe. It creates a new resource: a new > username/password pair with a defined validity. That's like claiming that every time I hit cnn.com, it creates a new resource, since the organization of the articles and ads changes as a function of time (new articles are added) and local cookies (encoding my section preferences). I think both are kind of a tortured interpretation of resource creation. > But it's equally valid to try to pretend otherwise and use GET. After > all, most servers won't actually be allocating any state for these > things. I hope none of them do. It's kind of the main point of the whole draft. > p.s., I was going to let this slide, but this design is not RESTful, > no sense in pretending like it is. I'm not sure I agree with your assessment. Which of these six constraints do you believe are violated? http://en.wikipedia.org/wiki/Representational_state_transfer#Constraints /a From martin.thomson@gmail.com Mon Jul 8 15:30:34 2013 Return-Path: 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 042BF21F9AAE for ; Mon, 8 Jul 2013 15:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, 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 svZUSfjxk5f3 for ; Mon, 8 Jul 2013 15:30:33 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3382321F9A3C for ; Mon, 8 Jul 2013 15:30:33 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so4215395wgh.14 for ; Mon, 08 Jul 2013 15:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A8eH8/aK3T4xvnbLeHff86CAZ8r0aON9ICVf2uHKH3M=; b=w4Ei3sT8kVm4Mm5GWF/A9ATyzqN+EYwNPPtMoN3gP/+Zcgo9WFHOjIm4BpUpmiUNe+ Jhjt8JyWxnADZgdbmmGTKOPuWOkJePoNGlrz0Kijt4P/cqXpNinEEJ1St0/vHnJf/NfQ rkL4XUsrcfOnn4T5jzDBrnjQjBxK0a6pVo/bE/hfkevanosTAxLB2BZ5E5TR9jw3clkp cLtLDOXfLpUBvdjVWMWHkfITuMFqHK5FVdNoazSQucJfMaidigEizAa227ZnOr1tzyfe hBEMYkOZyw3SXLsiwTncahPz+a39Iz23eF/QF/+OT+H+Y3bwjgsarR4aAGIvEfKn2wvL 1rBA== MIME-Version: 1.0 X-Received: by 10.194.77.99 with SMTP id r3mr13478131wjw.5.1373322632376; Mon, 08 Jul 2013 15:30:32 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 8 Jul 2013 15:30:32 -0700 (PDT) In-Reply-To: <51DB37C5.3060701@nostrum.com> References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DB3443.6070301@nostrum.com> <51DB37C5.3060701@nostrum.com> Date: Mon, 8 Jul 2013 15:30:32 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 22:30:34 -0000 On 8 July 2013 15:05, Adam Roach wrote: >> But it's equally valid to try to pretend otherwise and use GET. After >> all, most servers won't actually be allocating any state for these >> things. > > I hope none of them do. It's kind of the main point of the whole draft. I expect all of them to do so, but not hold clients responsible for that, so GET is still OK. >> p.s., I was going to let this slide, but this design is not RESTful, >> no sense in pretending like it is. > > I'm not sure I agree with your assessment. Which of these six constraints do > you believe are violated? > > http://en.wikipedia.org/wiki/Representational_state_transfer#Constraints Will you think worse of me if I avoid opening this particular can of worms? I regret even mentioning it. I've learned not to use the term RESTful, I should have known better. From juberti@google.com Mon Jul 8 17:51:20 2013 Return-Path: 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 A157D11E80EC for ; Mon, 8 Jul 2013 17:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] 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 sv2rifYLUCsQ for ; Mon, 8 Jul 2013 17:51:20 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA0211E80E6 for ; Mon, 8 Jul 2013 17:51:15 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k14so4211716wgh.17 for ; Mon, 08 Jul 2013 17:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kNtM2S/i+X746YoxY20yFFd0sZgZ98joElZYTKx1Lag=; b=nqBvq8NK5Usqb087NbPbM402E1W9fsKnK6STvlh/OCFlpW4NjAp96Qhe5b9MfW6gwk UgrKGttNr1AjKi0pTgsNVU5KepR4g3MBXriSUZgZBMdGg5lQ8fr7dIbAiQBxEpzP2zvK IKgBewBZD7Mxa04Ovvlj1NBzWzYOp2mY2fZWZqyc9MtaSPrbRKF6bd15xGXi6PssQDak fWEvTcbJv13AdUEsrPXpUItVRkLbN0/G89Je1maPIpFemFUIgoI3l6fGZX3tHpII2H+u ZCDnRbBijoqtNbfurEA0/wYLU7yGjUthtsaD01FFcnVYzo26EdqaS2EHsv3I6m4tf0AU SmUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=kNtM2S/i+X746YoxY20yFFd0sZgZ98joElZYTKx1Lag=; b=EH5c4zmXkxHkqUS5pR1q533JeX8/d3FkdaaEinFWsSrne2GCVLyOTbCKXKNj8vag4/ uTW32HA1f9KIlLhl079luH7QyIiuKghPXN8toN0KGCzNmt4Rxd2iqgmNgWdzHElIoTrK Ypkm+N5v6PbJ+8UiXaWoTA7kh9vYT6YA6TfAZUgAyQ/O/cV4SgiOSqwkY6gbCWHmOGnw xuaMHmaTYHMfMQ5n6H+lipBjKYIQSPOB0JjW8TQVWgTThCBrlQyIkx2DNls2aZ+XBSCF d7++s9tRuUVuHQYzctk6gyFFdkKWpcXbBeijXAN0rsWRsuN7G0q8MjhSs2jknU4h2R+W AKfA== MIME-Version: 1.0 X-Received: by 10.194.243.129 with SMTP id wy1mr13536726wjc.47.1373331075056; Mon, 08 Jul 2013 17:51:15 -0700 (PDT) Received: by 10.194.62.113 with HTTP; Mon, 8 Jul 2013 17:51:14 -0700 (PDT) Received: by 10.194.62.113 with HTTP; Mon, 8 Jul 2013 17:51:14 -0700 (PDT) In-Reply-To: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DAAF4B.4070004@viagenie.ca> Date: Mon, 8 Jul 2013 20:51:14 -0400 Message-ID: From: Justin Uberti To: Martin Thomson Content-Type: multipart/alternative; boundary=089e01493e00e35a5304e1098e57 X-Gm-Message-State: ALoCoQm87GfFhVRKYriPFScQr9jY9wD2FdY+aDZSmtayq4VJgiK/P0tnwW26TIihmf2ST/f6/Ld7FfQjp9MD7VQmYYRlxFGF4Wc8ZurDxiOijcEKTEoPlS+BaNjjp6kxdKcH0lxOxUBrVufwoinaijd4YLa4ixqXkLlr6HU3uzWQC7rMPGwbyHgMdLfTeNGi2q7KZvd6L92q Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 00:51:21 -0000 --089e01493e00e35a5304e1098e57 Content-Type: text/plain; charset=UTF-8 On Jul 8, 2013 5:43 PM, "Martin Thomson" wrote: > > On 8 July 2013 13:09, Justin Uberti wrote: > > The issue with using short term credentials, without a nonce, is the > > possibility of replay attacks by an eavesdropper. > > It is no less vulnerable than having the long term credential set > (username, nonce, realm, and password) overheard. Assuming that the > lifetime of the password is the same in both cases. In either case, > the link that the eavesdropper is required to attack is the HTTP link. I don't think this is true. In the short term case, with no nonce, the packet can be replayed verbatim. > > Passing realm and nonce solves this [...] > > I was suggesting that since you have spent some very expensive > round-trips getting this information, there are no advantages in > spending yet another round-trip on a challenge. I don't think that > passing realm and nonce is a good idea in practice - it creates a > tighter coupling between this new thing and the TURN server. > > In practice, a master nonce is not quite what you need, you need a > nonce-generator function, or a line to the TURN server whereby you > query for every request you get. The former imposes too-strong > constraints on implementations, the latter renders much of the > advantages of something like this moot. Right, the master nonce I suggested would be used to generate regular nonces. But it's not a good idea anyway. --089e01493e00e35a5304e1098e57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 8, 2013 5:43 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> On 8 July 2013 13:09, Justin Uberti <juberti@google.com> wrote:
> > The issue with using short term credentials, without a nonce, is = the
> > possibility of replay attacks by an eavesdropper.
>
> It is no less vulnerable than having the long term credential set
> (username, nonce, realm, and password) overheard. =C2=A0Assuming that = the
> lifetime of the password is the same in both cases. =C2=A0In either ca= se,
> the link that the eavesdropper is required to attack is the HTTP link.=

I don't think this is true. In the short term case, with= no nonce, the packet can be replayed verbatim.

> > Passing realm and nonce solves this [...]
>
> I was suggesting that since you have spent some very expensive
> round-trips getting this information, there are no advantages in
> spending yet another round-trip on a challenge. =C2=A0I don't thin= k that
> passing realm and nonce is a good idea in practice - it creates a
> tighter coupling between this new thing and the TURN server.
>
> In practice, a master nonce is not quite what you need, you need a
> nonce-generator function, or a line to the TURN server whereby you
> query for every request you get. =C2=A0The former imposes too-strong > constraints on implementations, the latter renders much of the
> advantages of something like this moot.

Right, the master nonce I suggested would be used to generat= e regular nonces. But it's not a good idea anyway.

--089e01493e00e35a5304e1098e57-- From silviapfeiffer1@gmail.com Mon Jul 8 20:03:35 2013 Return-Path: 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 E514A11E810F for ; Mon, 8 Jul 2013 20:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2-oe8oSEkM+m for ; Mon, 8 Jul 2013 20:03:34 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC0311E810E for ; Mon, 8 Jul 2013 20:03:34 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k14so7154342oag.26 for ; Mon, 08 Jul 2013 20:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Y5fz5gcx/E7cSFmUMGepsuGxBe8fIVPNy6g20vIFwtI=; b=rKL6mFvduDO49sOhUrE9SYZ3zUKvxWQVllqB/pMxEvf19boX19folYeZrrHPmOjQIR GTvCRa1QyqeoPAfd3ojK3lwGn/MA9uMsfB/6Ne4WYBs/e9ufwxer7hzf4HwqLH9F0T8e 7ru2sAWPPJ0IuohQQ0O2tPVmQCPFwtho1m7jr4YGg+FXgMNzmORZRYbG463eSpXnk9nN CiviCy/fScXd7i3uYHmpawk3HaYrVu6CA6eT1RmB1QPTTfwzhULD8P9BzTJCqyk8zPAx dv/2LppZJrws4LV1JOn5Tq0ggnabtVFJbJkx1IxyQVw2Dq0M8Cw9ERJUV0XBN71r4h9L oLxA== X-Received: by 10.182.61.46 with SMTP id m14mr22717402obr.58.1373339012170; Mon, 08 Jul 2013 20:03:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.173.106 with HTTP; Mon, 8 Jul 2013 20:03:12 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> From: Silvia Pfeiffer Date: Tue, 9 Jul 2013 13:03:12 +1000 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=ISO-8859-1 Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 03:03:35 -0000 On Tue, Jul 9, 2013 at 12:38 AM, Peter Thatcher wrote: > > No objections at all? That is rather surprising to me. I asked for some > feedback the API in the spreadsheet from web developers, at there many > objections from them about this part of the API. A majority did say it was > good enough for simple use cases, but he objections were still clearly > non-zero. > > I think perhaps the web developers are not well represented at TPAC. But I > could be wrong. Perhaps they are but changed their mind. Or maybe they're > objecting on the IETF mailing list when they should object on the IETF > mailing list. Or maybe the spreadsheet has a sample bias, while TPAC is > the true sample. I don't know, but it seems like something is going on, > and I'd like to know what it is. > > Stefan, what do you think? What could explain the apparent contradiction > between objections on the mailing list vs. no objections f2f? I'm not Stefan, but I have a theory. I think there are two groups objecting and there are two things to object against. Here's what I'm reading... Web Developers really just want to be given functionality. They can build their own nice API on top of what browsers implement (jquery did a marvellous job of that). But they want functionality. Seeing as some things are not currently possible with SDP and O/A, they either want to extend those to allow their functionality, or - in particular where SDP & O/A are overkill - want an option to get out of using SDP & O/A and use something else. Telco engineers want their existing devices to be interoperable with browsers as well as the ability to develop new devices in the future with extended functionality. So, on behalf of the first goal, they object to including functionality into SDP that other devices don't already support, and on behalf of the second goal, they are torn between extending SDP & O/A and starting new. As to why you haven't seen anyone object at the TPAC (did you really mean TPAC, btw? The next TPAC meeting is only in November) - maybe none of the people of these two groups were present at last year's TPAC? Or they didn't understand the consequences yet.... Also, it's easy to object on a mailing list, while in a meeting room, you'd have to provide an alternative and it's really hard to come up with such an alternative IMHO. I certainly want a simple API, but I am not sure whether what we currently have is already the simplest possible (given current circumstances), nor am I sure whether it wouldn't just be possible to build a simple one on top the jquery way, which would be sufficient for now. HTH, Silvia. From martin.thomson@gmail.com Mon Jul 8 20:44:06 2013 Return-Path: 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 0C3A621F9AC2 for ; Mon, 8 Jul 2013 20:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, 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 2snYoRZYDmop for ; Mon, 8 Jul 2013 20:44:05 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3C721F9AA9 for ; Mon, 8 Jul 2013 20:44:05 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so4334001wes.3 for ; Mon, 08 Jul 2013 20:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kHMgG97EsKokaAyurpwwcbg2P1/ReWn18d3dWpFFmyU=; b=hNXDn3TiNPePNCVgTvZeUdwUYJZoF3eFHGJA+apSV2jdeEpAM/sF6nC44gAAXnUj3j 21Q/q0lrBj2oYuap3ETZKPhMuSLJov/BUzTAGAUpK07R9Q+VTnTDdkTr4Eye1lAQhKRo 8jOcfxVi9OjTly3JuKbVAyclQ8UcfTAkzW961p4nqrVVW42EMekom3puLfmAH2s9vUMB k9MDFi87Qba36g91mYXnitRLo/4DeUO0Js0MS1t/l4egHZmPi8Sx6dJaaaAgE8acZJV+ bJfOfBtAXbsZH9hk9BUSMkYVmVx/L9WsNt/28gq7WVAdDElvL7LhyyZTPrWTdb+bxvXl QNkg== MIME-Version: 1.0 X-Received: by 10.180.9.212 with SMTP id c20mr30637213wib.65.1373341444532; Mon, 08 Jul 2013 20:44:04 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 8 Jul 2013 20:44:04 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> Date: Mon, 8 Jul 2013 20:44:04 -0700 Message-ID: From: Martin Thomson To: Silvia Pfeiffer Content-Type: text/plain; charset=UTF-8 Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 03:44:06 -0000 On 8 July 2013 20:03, Silvia Pfeiffer wrote: > Or they didn't understand the consequences yet.... Also, it's > easy to object on a mailing list, while in a meeting room, you'd have > to provide an alternative and it's really hard to come up with such an > alternative IMHO. Hey Silvia, We were there, in person, in Lyon, last November, but there were just two of us. We even had a viable alternative. It's easy to dismiss two people. Almost as easy, if not even easier, to dismiss an absent mass. From silviapfeiffer1@gmail.com Mon Jul 8 20:49:58 2013 Return-Path: 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 3FF8B11E8110 for ; Mon, 8 Jul 2013 20:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BtcvzoGWnJOf for ; Mon, 8 Jul 2013 20:49:57 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id CA17121F9BB5 for ; Mon, 8 Jul 2013 20:49:57 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so7244212oah.21 for ; Mon, 08 Jul 2013 20:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=phYFJd1HwKLnmCYjgGupzC0Y9REm/zVlJhbus9Rd1Ls=; b=JF/9uSYe68NIPb2NH3S3TybecyOR1IpRkD+NYybKgF4h0bN4SoH8zGkQf4IKJe2pZk gVI5xsj7Nue42lLK4JjwM2+4UPtVXNOASHTHt5CGxsnsVonhkh65d03p9Hvv/jaSncSW hxTWIeZrmVMfF55V4Il/KUm0odBWCqEB8xHOBdgd6N1HEHWZPzaq/M8ZZaL6bwowU89i /yIcvudZVq2Q+xcv+sn7bi2K+5OnuEVfIxEOt5vvL9iUoarsVE4DZYYPfPdwKkTH7lFT /VlHtalBSRU1ohlkGhBeQTZmw9OPb0yHo7Owk+Mpf5vPlxDGjgcS0xUi6HHKs0ao2T8s u0OA== X-Received: by 10.182.61.46 with SMTP id m14mr22815656obr.58.1373341797068; Mon, 08 Jul 2013 20:49:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.173.106 with HTTP; Mon, 8 Jul 2013 20:49:37 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> From: Silvia Pfeiffer Date: Tue, 9 Jul 2013 13:49:37 +1000 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 03:49:58 -0000 On Tue, Jul 9, 2013 at 1:44 PM, Martin Thomson wrote: > On 8 July 2013 20:03, Silvia Pfeiffer wrote: >> Or they didn't understand the consequences yet.... Also, it's >> easy to object on a mailing list, while in a meeting room, you'd have >> to provide an alternative and it's really hard to come up with such an >> alternative IMHO. > > Hey Silvia, > > We were there, in person, in Lyon, last November, but there were just > two of us. We even had a viable alternative. Right! > It's easy to dismiss two people. Almost as easy, if not even easier, > to dismiss an absent mass. Agreed. But I think things are different now that there is so much more experience so maybe next TPAC will look different. Cheers, Silvia. From stefan.lk.hakansson@ericsson.com Tue Jul 9 00:40:38 2013 Return-Path: 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 3AA9821F9A92 for ; Tue, 9 Jul 2013 00:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.342 X-Spam-Level: X-Spam-Status: No, score=-5.342 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 cgs9EJzZptoI for ; Tue, 9 Jul 2013 00:40:33 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 46EAA21F91B4 for ; Tue, 9 Jul 2013 00:40:31 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-a9-51dbbe6ee970 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F3.00.05990.E6EBBD15; Tue, 9 Jul 2013 09:40:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Tue, 9 Jul 2013 09:40:30 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Martin Thomson Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOeDFbTNRhHYI3NkSZeqhrbqmeQg== Date: Tue, 9 Jul 2013 07:40:29 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+JvrW7evtuBBvevyFlcO/OP0WLtv3Z2 i5W3LrA4MHvsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBmzP/QzFhzirZg+N7qB8S9XFyMn h4SAiUTDqxNMELaYxIV769m6GLk4hAQOM0rMnNjDBpIQEljIKDH1cC6IzSYQKLF13wKwuIiA rsSisw/YQWxmgQiJlglbWUBsYYEqieWHjwHFOYBqqiWW9JdDlOtJdF2EKGERUAHatYQVxOYV 8JU4/X8tC8Tek6wSj/fPZAZJMAId9P3UGiaI+eISt57MhzpUQGLJnvPMELaoxMvH/1ghbCWJ HxsusUDU60ncmDqFDcLWlli28DUzxDJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUje25i Zk56udEmRmBMHNzyW3UH451zIocYpTlYlMR5N+udCRQSSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXAuKu87JTRrFePlRNy3crCjs6Wm7Rx1oLSjZ+rzpWe+X3daEFn5JPbadwOD1Vlb8l85nw7 0TE0NU5g6eovgU/ShN3OTHvse8/o9+k7bgt+chlGNrobT/Yo5XOZpSsgcGe+uXz05wVxaerv bjMpPkpc79bPKb/eQEIm0Y7JseK6Vmvpl+9/18aUK7EUZyQaajEXFScCAGqZQE5XAgAA Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 07:40:38 -0000 On 7/9/13 5:44 AM, Martin Thomson wrote:=0A= > On 8 July 2013 20:03, Silvia Pfeiffer wrote:= =0A= >> Or they didn't understand the consequences yet.... Also, it's=0A= >> easy to object on a mailing list, while in a meeting room, you'd have=0A= >> to provide an alternative and it's really hard to come up with such an= =0A= >> alternative IMHO.=0A= >=0A= > Hey Silvia,=0A= >=0A= > We were there, in person, in Lyon, last November, but there were just=0A= > two of us. We even had a viable alternative.=0A= =0A= I want to be very clear and careful on what I say. So I am repeating:=0A= =0A= * My comment that I think Eric is right in that there is consensus on =0A= providing APIs that allow most use-cases to be met without SDP mangling =0A= is meant only in that context: SDP O/A is kept (and PeerConnection more =0A= or less as is and so on).=0A= =0A= I don't think Martin or anyone else objected to this in Lyon or at any =0A= other discussion.=0A= =0A= It is also true that an alternative API proposal, CU-rtcweb, was brought = =0A= forward to the WebRTC WG earlier during 2012. The WG took this under =0A= consideration, and (at that time) decided to continue developing based =0A= on the PeerConnection API including SDP O/A.=0A= =0A= I think the discussion in Lyon only evolved around PeerConnection (wiht =0A= SDP O/A), we did not discuss other API alternatives.=0A= =0A= >=0A= > It's easy to dismiss two people. Almost as easy, if not even easier,=0A= > to dismiss an absent mass.=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From ibc@aliax.net Tue Jul 9 03:09:44 2013 Return-Path: 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 5260621F9FC8 for ; Tue, 9 Jul 2013 03:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 NQi6KaT7cnX1 for ; Tue, 9 Jul 2013 03:09:39 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 09B0D21F9FA4 for ; Tue, 9 Jul 2013 03:09:38 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so2789499qab.8 for ; Tue, 09 Jul 2013 03:09:37 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=Pzd2FV/Sn5ZS+vmvvH8A59pG9RzPN62vF0bqvXma4R8=; b=behGv1IIQE3W3E1SDkaz0O3NyeziLeremPflI+cL0HW0YUZQsjFg3JNwVL4QEjDRQi eGlfoIb+zTCBZdcE+3/2xJI0oUNrj1dxyn58rZjbb2x+b7osLDc0i6enR1dRWUgdyzW/ iFgBa0RSvOcxGoNBNpGC0ULlOZC1nF6+SNH94PnepK/M/6IkObpOoDUxXpaP2Py2IIo4 wYyKGYdMgtQGeZmjPP8pGyNjF4rgKebsVf1FBbgrrJXKnASEaFi13pA2PkBGlX/pbP+c tCOFHTHgTdZj1PhHBP/VrTpwaQd24mO9kZJIXahsxDEkaG7Q5UiLQvlXo8zg17WmLdM+ AdKQ== X-Received: by 10.224.114.207 with SMTP id f15mr7749629qaq.115.1373364577481; Tue, 09 Jul 2013 03:09:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 9 Jul 2013 03:09:17 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 9 Jul 2013 12:09:17 +0200 Message-ID: To: Silvia Pfeiffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk9L19kHnJWTNaCd+HlbSA8VkftvuIIIyfqAOaQmS58HOITKwxQoj/gUqTGGgUuA7G+CW7I Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 10:09:44 -0000 2013/7/9 Silvia Pfeiffer : > I think there are two groups objecting and there are two things to > object against. > > Here's what I'm reading... > > Web Developers really just want to be given functionality. They can > build their own nice API on top of what browsers implement (jquery did > a marvellous job of that). But they want functionality. Seeing as some > things are not currently possible with SDP and O/A, they either want > to extend those to allow their functionality, or - in particular where > SDP & O/A are overkill - want an option to get out of using SDP & O/A > and use something else. > > Telco engineers want their existing devices to be interoperable with > browsers as well as the ability to develop new devices in the future > with extended functionality. So, on behalf of the first goal, they > object to including functionality into SDP that other devices don't > already support, and on behalf of the second goal, they are torn > between extending SDP & O/A and starting new. Hi Silvia, Another important point is that many of those telco engineers have clearly recognized that they don't know Web, nor JS, nor designing JS APIs for the Web, and that they just want WebRTC to be compatible with their current business (literally: "I want browsers to be compatible with SIP"). For example, two years ago the initial proposal by many of those telco engineers was "allow plain RTP and mandate SIP as in-the-wire protocol for WebRTC" (this is true). I also remember that somebody proposed that the browser should include a "call history" panel, which clearly shows a limited and wrong WWW vision. They strongly think that by mandating SDP O/A they are done and have accomplished their job in this WG on behalf of their big companies (those that have never succeeded in the WWW). And of course, they are much more used to IETF processes than Web guys (is Facebook represented in this WG?), thus the only argument they expose *nowadays* is: "SDP mandate was talked about and agreed two years ago in a meeting full of telco engineers". And then, the current spec is basically an opaque and unmanageable SDP blob generated by the browser that must be sent by the JS to the peer. The same "logic" within a phone. But here is the problem: a web application is all but **fixed** code and **fixed** logic. Don't kill the Web. > I certainly want a simple API, but I am not sure whether what we > currently have is already the simplest possible (given current > circumstances), What we have now is not a real API. > nor am I sure whether it wouldn't just be possible to > build a simple one on top the jquery way, which would be sufficient > for now. An API should be good enough to not require an extra layer on top of it to make it feasible for developers. As developer in JsSIP project I must say that we have properly implemented SIP pure protocol on top of JS and WebSocket, no problems at all (regardless how complex SIP becomes sometimes). The only real problem we have if related to WebRTC "API". Tons of hours dealing with unexpected/wrong specifications and behaviors (and yes, SDP blob hackery). We would be very happy if we could generate our *own* SDP with JS (which means we need to retrieve *real* JS Objects from the WebRTC stack rather than an opaque SDP blob). And telcos, ey!!!, we are doing SIP even much more than you !!! believe us !!! Best regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Jul 9 03:18:27 2013 Return-Path: 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 27E3621F9FC3 for ; Tue, 9 Jul 2013 03:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 6+KhgvHPGtZP for ; Tue, 9 Jul 2013 03:18:22 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id ED28721F9F96 for ; Tue, 9 Jul 2013 03:18:21 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so2856977qcy.4 for ; Tue, 09 Jul 2013 03:18:21 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=JG6oDzcXZolkdqktalvASJcKba2OoRsNZzUPIkYlVVs=; b=Xg50X3hDvJ8svGglmLsMQ2kJkowvWB0fA2vT0qXfhyXXI2ltDvA40X31SZ3X7euxww TLBpULnUOrU+1t5PfbMGP6SK8R61tGJELgqI+DrYULlrMdQOgJbH3nzL4ed6s2ELIm4j VndoRfh65NFhKMAOsVpSoMExs5b7USQ/gL1xXzuB1gwro22Yj5+ERvSNPUPV+LOTQfcT k61+AePHPmWMsDJw9O4gZhUoBHN5rPsqCns8lM6hEFw4hkP67/1g4GHWQbajvLzFKnHD jg3DvcDXu8Cos3HYdyEt+6cWjIQ+AujES00KRve9zp5bfC513Jt8mKhUO2cVMr82XqE9 TJgA== X-Received: by 10.49.61.167 with SMTP id q7mr19879948qer.80.1373365101037; Tue, 09 Jul 2013 03:18:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 9 Jul 2013 03:18:00 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 9 Jul 2013 12:18:00 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl6fuLJkf4JMgWaYKG8f6RMr48wCO01yo+bgl/ySgASXFeVZPvpjQHt9501haGcsYjkNl/Y Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 10:18:27 -0000 2013/7/9 Stefan H=C3=A5kansson LK : > I want to be very clear and careful on what I say. So I am repeating: > > * My comment that I think Eric is right in that there is consensus on > providing APIs that allow most use-cases to be met without SDP mangling > is meant only in that context: SDP O/A is kept (and PeerConnection more > or less as is and so on). Hi Stefan, You insist that "there is consensus on keeping SDP O/A but providing a better API". Given current discussions IMHO it is clear there is not such a consensus (not at all). Or may be you are just talking about two years ago in some IETF meeting (if so I'm sorry). Please review the results in https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdHlZ= dV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1 Bad for advanced stuff: 94% OK for 1.0: 40% IMHO such a result indicates all but "let's keep SDP O/A and improve a bit the API" (I mean now, in July 2013). Best regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Jul 9 03:40:53 2013 Return-Path: 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 92AE021F9CC2 for ; Tue, 9 Jul 2013 03:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 SNwfTUQSKtEZ for ; Tue, 9 Jul 2013 03:40:48 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 67CB221F9C74 for ; Tue, 9 Jul 2013 03:40:48 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e10so2832010qcy.41 for ; Tue, 09 Jul 2013 03:40:47 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=OD2XhML0xoiYkaNeaCZgL0R3moyrMyqRJzIWeoqj87w=; b=LtBCj7dOifFtkRo2n1HnqHiIMS6W/OhE/Fi+NAsyXmU9I+Ow4BZ8ws9rE7jLhDwZyZ q3LCV2ON5k4NiC2qb3JsOluF4dSKaz7Fes/BXmTeiqfj5l7aqig4D2p+kFOhUu6/JF3v opiegMYb6fQJ0WjjVIC9DOQ1LtJ/HtqHelZxh/Uc6TSxyiZ7ERROzAt7gVWAJHpQWuol iD7FlJNb1zzKE3jwQTy2xSvfGi5NQD122xCt7Nj7YaM3hTDk8s/5YZBxe5w/0S4B3NuC L1RsbWv4qSkWfiHp/DH7nPVl2NMfjB9Rmr7pBgdTkcdGbePb4SFQ7wIL0XT5oFQb0L9l FeGg== X-Received: by 10.224.182.79 with SMTP id cb15mr23042541qab.48.1373366447881; Tue, 09 Jul 2013 03:40:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 9 Jul 2013 03:40:27 -0700 (PDT) In-Reply-To: <201305102015.r4AKFASK4512588@shell01.TheWorld.com> References: <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <201305102015.r4AKFASK4512588@shell01.TheWorld.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 9 Jul 2013 12:40:27 +0200 Message-ID: To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl2KX/dTtSk1/2VxBe7R3xrUmL8vRl5EWnWfMPchpX0LvcHWVK0lQzKPren1VKPrIgxgPqm Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Reducing glare X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 10:40:53 -0000 2013/5/10 Dale R. Worley : > Two possible solutions for glare problems come to mind: > > One is to require the designated "follower" to accept and give a 200 > response to an incoming re-INVITE even if it has an outstanding > re-INVITE. The difficulty that follows is that the follower doesn't > know whether the "leader" has accepted or rejected its re-INVITE until > the response arrives, so there is an interval (between sending the 200 > to the leader's re-INVITE and receiving the leaders response to its > re-INVITE) during which the follower doesn't know its outgoing media > configuration. We could probably fix that by annotating the leader's > offers with the o=3D value of the follower's SDP that the leader > currently is using. > > A second one would be to simply drastically shorten the glare backoff > timer. Given that we're talking about video systems, the RFC 3261 > timer ranges of 0 to 2 secs and 2.1 to 4 secs are very slow. If we > cut those times by a factor of 10, wouldn't the user-visible problems > nearly vanish? A third and better solution would be to stop assuming that SIP problems are also WebRTC problems. The "glare" problem occurs due to the artificial mandate of SDP O/A in WebRTC. Want to avoid the "glare" problem and "SDP v=3D" number problem? Remove SDP O/A from WebRTC and you are done. Then if somebody wants to play with SDP at JS it can do it **at JS level**. -- I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Tue Jul 9 04:26:46 2013 Return-Path: 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 810A121F972C for ; Tue, 9 Jul 2013 04:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=-1.258, BAYES_00=-2.599, 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 22FjmzRWn4xb for ; Tue, 9 Jul 2013 04:26:40 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D395321F9FD2 for ; Tue, 9 Jul 2013 04:26:39 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-2b-51dbf36d54fd Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id AD.18.11907.D63FBD15; Tue, 9 Jul 2013 13:26:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Tue, 9 Jul 2013 13:26:37 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOeDFbTNRhHYI3NkSZeqhrbqmeQg== Date: Tue, 9 Jul 2013 11:26:37 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30D110@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrW7e59uBBne7WC2m77OxuHbmH6PF 2n/t7A7MHuca3rN77Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZ/x59Yyq4xVexZ/5y9gbG N9xdjJwcEgImEp3Xp7FA2GISF+6tZ+ti5OIQEjjKKHH922FmkISQwEJGiQ1zZUFsNoFAia37 FrCB2CIClhI35t4Eq2EWCJN4+38mE4gtLFAlsfzwMfYuRg6gmmqJJf3lEOV6El0Xt4LtYhFQ kXh0v4MRxOYV8JXoPraGHWLvFTaJvi3/WUESjEAHfT+1hglivrjErSfzmSAOFZBYsuc8M4Qt KvHy8T9WCFtRYufZdqh79CRuTJ3CBmFrSyxb+JoZYpmgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsoqRozi1OCk33chgEyMwPg5u+W2xg/HyX5tDjNIcLErivFv0zgQKCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYLyUWp5ZKSH0J3POclMt3aC40xrbj9jmrZFIvHVGaspLz/CP3YvLZNSC L6qYlrKqPQtao/XWlvlzgsAU+Q+m7kK/HYweHrlyV4Lx6lOjudcTRY0P2b/J9M2ZE3TUb9of 0axjLxSmb2oryPC49591irdEmVBaSO6V3S1deSf3/87zbXl96qTAASWW4oxEQy3mouJEAApD cF5dAgAA Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 11:26:46 -0000 On 2013-07-09 12:18, I=F1aki Baz Castillo wrote:=0A= > 2013/7/9 Stefan H=E5kansson LK :=0A= >> I want to be very clear and careful on what I say. So I am repeating:=0A= >>=0A= >> * My comment that I think Eric is right in that there is consensus on=0A= >> providing APIs that allow most use-cases to be met without SDP mangling= =0A= >> is meant only in that context: SDP O/A is kept (and PeerConnection more= =0A= >> or less as is and so on).=0A= >=0A= > Hi Stefan,=0A= >=0A= > You insist that "there is consensus on keeping SDP O/A but providing a=0A= > better API".=0A= =0A= I must be expressing myself quite badly, because the message seems not =0A= to get through.=0A= =0A= * I think we have consensus on adding API that allows most use-cases to =0A= be met without SDP mangling (given that SDP O/A is kept naturally)=0A= =0A= * We discussed last year an alternative API that did not use SDP at all =0A= (and did not use PeerConnection). The decision at that time was to =0A= continue developing the API based on PeerConnection and SDP O/A.=0A= =0A= Have not stated anything more than that.=0A= =0A= Stefan=0A= =0A= > Given current discussions IMHO it is clear there is not=0A= > such a consensus (not at all). Or may be you are just talking about=0A= > two years ago in some IETF meeting (if so I'm sorry).=0A= >=0A= > Please review the results in=0A= > https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdH= lZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1=0A= >=0A= > Bad for advanced stuff: 94%=0A= > OK for 1.0: 40%=0A= >=0A= > IMHO such a result indicates all but "let's keep SDP O/A and improve a=0A= > bit the API" (I mean now, in July 2013).=0A= >=0A= >=0A= > Best regards.=0A= >=0A= >=0A= >=0A= > --=0A= > I=F1aki Baz Castillo=0A= > =0A= >=0A= =0A= From ted.ietf@gmail.com Tue Jul 9 08:33:09 2013 Return-Path: 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 84CD621F9D24 for ; Tue, 9 Jul 2013 08:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, 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 tCqE4MHGWeH8 for ; Tue, 9 Jul 2013 08:33:09 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 128EB21F9EE6 for ; Tue, 9 Jul 2013 08:33:08 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so13381463ied.0 for ; Tue, 09 Jul 2013 08:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=b6QlIFM+8TZQ2ZXbloa5+C5MFnLrhPAQ3smNUQ7LWJU=; b=oTVxS89yEKLTe8UENkiXtqL+9NlqFEPrJ4JuCfjP3RHfOn3wab8JqIre4NiYdBdRBV 9F4rfD5Asz/ahaMf3o5XEiuPxZn2NbsQvpaYLCChu8dA1J0PTsftInPqRIZHEDlImxgp 1DDI+m3Y/Gf2cKXONdL0FVCnwUKNpk9HrpzAcynOf/egR6IfhuI7sB3voFzXl9H9ReHH MWWHSEh4cRZ3Zran6ZOnIJwlVhyCD7ceLJ8zcQR6az8cu4/aHGuu5PJAWm43KdTJ2eeI wR1BWnWQu5tRRQzIhfsjPMAI4O5s6pB5Uo7fzF+3ygVGxroULUjdaeJ/UUW/Wjj/E/xd Tv8Q== MIME-Version: 1.0 X-Received: by 10.42.52.6 with SMTP id h6mr8706289icg.5.1373383988704; Tue, 09 Jul 2013 08:33:08 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Tue, 9 Jul 2013 08:33:08 -0700 (PDT) Date: Tue, 9 Jul 2013 08:33:08 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org, public-webrtc@w3.org Content-Type: multipart/alternative; boundary=20cf3036361fc983b104e115e0b4 Subject: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:33:09 -0000 --20cf3036361fc983b104e115e0b4 Content-Type: text/plain; charset=ISO-8859-1 Howdy, The recent set of API discussions has been spread across both the rtcweb and public-webrtc mailing lists. That's making it both harder to follow and harder for folks to work out who is saying what under which rules. The chairs of both groups believe that the right place for the discussion to continue should be public-webrtc. Please direct follow-ups on this topic to that list. regards, Ted Hardie --20cf3036361fc983b104e115e0b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howdy,

The recent set of API discussions has been spread across both= the rtcweb and public-webrtc mailing lists.=A0 That's making it both h= arder to follow and harder for folks to work out who is saying what under w= hich rules.=A0 The chairs of both groups believe that the right place for t= he discussion to continue should be public-webrtc.=A0 Please direct follow-= ups on this topic to that list.

regards,

Ted Hardie
--20cf3036361fc983b104e115e0b4-- From derhoermi@gmx.net Tue Jul 9 10:26:33 2013 Return-Path: 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 CBA3B21F9EFF for ; Tue, 9 Jul 2013 10:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 p0JS1YBEcJqL for ; Tue, 9 Jul 2013 10:26:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 35BB421F9E01 for ; Tue, 9 Jul 2013 10:26:20 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.39.121]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0Ldttv-1UXCXi0kzb-00j0BY; Tue, 09 Jul 2013 19:26:11 +0200 From: Bjoern Hoehrmann To: cowwoc Date: Tue, 09 Jul 2013 19:26:08 +0200 Message-ID: References: <51DC3644.4020107@bbs.darktech.org> In-Reply-To: <51DC3644.4020107@bbs.darktech.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:5s1D8fWbuK/EuTYpHDCGQCdYLJMCm6LXV5ZE0+yRJflalu744ER zswa6oug3U9iWsoBpgNk0GfamPIxt0WwKqwfNYct8ngWyYGsTXUOVf8XwPFkMQQi7k8MfNy lEMgxXSeOXsL7pohgRfR5GnzXuJUUmYODIhiCTOuKE8IQYWnpLpKtA5Kp++RrR+mfQ/Ctzg Bhn2zEPPR/Z/5ZKbHESkQ== Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 17:26:33 -0000 * cowwoc wrote: > I agree, with one caveat: virtually none of the high-level >stakeholders (spec editors, browser vendors, etc) bother to engage the >community on public-webrtc. W3C's Web Real-Time Communications Working Group is required to address all feedback it receives in a timely and technically sound manner. Take http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0081 up Anne van Kesteren's offer to help if that is not working out for you. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From matthew.kaufman@skype.net Tue Jul 9 11:05:06 2013 Return-Path: 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 7EA6B21F9EE5 for ; Tue, 9 Jul 2013 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 XkW1gt+1ViT6 for ; Tue, 9 Jul 2013 11:05:00 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECE521F9EB7 for ; Tue, 9 Jul 2013 11:04:59 -0700 (PDT) Received: from BN1BFFO11FD021.protection.gbl (10.58.52.203) by BN1AFFO11HUB032.protection.gbl (10.58.52.142) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 9 Jul 2013 18:04:58 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD021.mail.protection.outlook.com (10.58.53.81) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Tue, 9 Jul 2013 18:04:58 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.70]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Tue, 9 Jul 2013 18:04:23 +0000 From: "Matthew Kaufman (SKYPE)" To: Ted Hardie , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: [rtcweb] Locus of API discussion Thread-Index: AQHOfLmwMutMwraSzEud0Hjh6FFtPplco6vQ Date: Tue, 9 Jul 2013 18:04:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841D143E48TK5EX14MBXC274r_" 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)(377454003)(199002)(80022001)(56816003)(33656001)(77096001)(20776003)(512954002)(47976001)(16236675002)(4396001)(81542001)(19300405004)(53806001)(16406001)(66066001)(74502001)(65816001)(15202345003)(47736001)(46102001)(6806003)(51856001)(83072001)(74706001)(59766001)(50986001)(69226001)(54316002)(56776001)(49866001)(77982001)(76482001)(31966008)(76796001)(74366001)(71186001)(79102001)(76786001)(54356001)(74876001)(47446002)(63696002)(81342001)(74662001)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB032; H:TK5EX14HUBC102.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: 0902222726 Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:05:06 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841D143E48TK5EX14MBXC274r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Could you explain the reasoning behind moving the API discussion to the W3C= list while leaving the actual API specification documents as Internet Draf= ts created and edited by the IETF WG? I'm all for moving the API work (back) to W3C, but we should move all of it= , don't you think? Matthew Kaufman From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ted Hardie Sent: Tuesday, July 9, 2013 8:33 AM To: rtcweb@ietf.org; public-webrtc@w3.org Subject: [rtcweb] Locus of API discussion Howdy, The recent set of API discussions has been spread across both the rtcweb an= d public-webrtc mailing lists. That's making it both harder to follow and = harder for folks to work out who is saying what under which rules. The cha= irs of both groups believe that the right place for the discussion to conti= nue should be public-webrtc. Please direct follow-ups on this topic to tha= t list. regards, Ted Hardie --_000_AE1A6B5FD507DC4FB3C5166F3A05A4841D143E48TK5EX14MBXC274r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Could you explain the reasoning behind moving the API discussion to the = W3C list while leaving the actual API specification documents as Internet Drafts created and edited by the IETF WG?

 <= /p>

I’m all for moving = the API work (back) to W3C, but we should move all of it, don’t you t= hink?

 <= /p>

Matthew Kaufman

 <= /p>

From: rtcweb= -bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, July 9, 2013 8:33 AM
To: rtcweb@ietf.org; public-webrtc@w3.org
Subject: [rtcweb] Locus of API discussion

 

Howdy,

The recent set of API discussions has been spread across both the rtcweb an= d public-webrtc mailing lists.  That's making it both harder to follow= and harder for folks to work out who is saying what under which rules.&nbs= p; The chairs of both groups believe that the right place for the discussion to continue should be public-webrtc.&nb= sp; Please direct follow-ups on this topic to that list.

regards,

Ted Hardie

--_000_AE1A6B5FD507DC4FB3C5166F3A05A4841D143E48TK5EX14MBXC274r_-- From robin@hookflash.com Tue Jul 9 12:43:26 2013 Return-Path: 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 F2E1321F9E83 for ; Tue, 9 Jul 2013 12:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 e-f1983PjPYU for ; Tue, 9 Jul 2013 12:43:21 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 6321E21F9E6E for ; Tue, 9 Jul 2013 12:43:20 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so13962444ied.0 for ; Tue, 09 Jul 2013 12:43:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=fFZah6OAjiBMYJY8rCBQE5iXWXeGdNpk1NqLrYSN/0g=; b=IZj9ZGP3T7iQ7X20M2uTFMYxMbnvP0edWKP+GfcY+Vhe38jbAkv5zRXTsssCmJbr8H qN+6XeZESdWc6yNerkDxRTjQTyzGB8Rj1kmKAXObgkUyFHJQ3NRnT+b1DSN3WOTgF1nP yPeo7TA7YUC2Ik3OfOkh5FcEmHox5w7rLHLCVcoYloxoeFe5LCAaL/edqlwfQNMWQeAJ YhORf61bPFUFrYWP5tVUIZEm78tWtcZRfpY6PHcmv06rZRHb65smLJ3ct++xerG0ZHSE 5seBwaH7pBCHAX2UeKZ7xx9IHZol6ryDISC4TGmtA5CCH2kMYlHi+BQGNBl1Nu4PiMxh PpLQ== X-Received: by 10.43.137.131 with SMTP id io3mr8866487icc.79.1373399000062; Tue, 09 Jul 2013 12:43:20 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id q10sm10816412ige.4.2013.07.09.12.43.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 12:43:19 -0700 (PDT) Message-ID: <51DC67D4.9050101@hookflash.com> Date: Tue, 09 Jul 2013 15:43:16 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Matthew Kaufman (SKYPE)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080803060801030407060808" X-Gm-Message-State: ALoCoQmRMurkiHXvnSOC9SmOH4muMMGZeDJ4FciH8TOSzfVAUfpVPVvy2S69sMok40h7BMg5XqLK Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 19:43:26 -0000 This is a multi-part message in MIME format. --------------080803060801030407060808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Agreed, and in addition, is SDP with offer / answer a mandated surface API by the RTCWEB WG or the W3C? (i.e. a mandate that some use cases are only solvable with touching the SDP, and web developer must know about offer/answer in the process) If so, which group is mandating that requirement be part of the web developer's API? This helps define which group is appropriate to address those kinds of concerns. -Robin > Matthew Kaufman (SKYPE) > 9 July, 2013 2:04 PM > > Could you explain the reasoning behind moving the API discussion to > the W3C list while leaving the actual API specification documents as > Internet Drafts created and edited by the IETF WG? > > I'm all for moving the API work (back) to W3C, but we should move all > of it, don't you think? > > Matthew Kaufman > > *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Ted Hardie > *Sent:* Tuesday, July 9, 2013 8:33 AM > *To:* rtcweb@ietf.org; public-webrtc@w3.org > *Subject:* [rtcweb] Locus of API discussion > > Howdy, > > The recent set of API discussions has been spread across both the > rtcweb and public-webrtc mailing lists. That's making it both harder > to follow and harder for folks to work out who is saying what under > which rules. The chairs of both groups believe that the right place > for the discussion to continue should be public-webrtc. Please direct > follow-ups on this topic to that list. > > regards, > > Ted Hardie > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > Ted Hardie > 9 July, 2013 11:33 AM > Howdy, > > The recent set of API discussions has been spread across both the > rtcweb and public-webrtc mailing lists. That's making it both harder > to follow and harder for folks to work out who is saying what under > which rules. The chairs of both groups believe that the right place > for the discussion to continue should be public-webrtc. Please direct > follow-ups on this topic to that list. > > regards, > > Ted Hardie > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------080803060801030407060808 Content-Type: multipart/related; boundary="------------080707040203050805030103" --------------080707040203050805030103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Agreed, and in addition, is SDP with offer / answer a mandated surface API by the RTCWEB WG or the W3C? (i.e. a mandate that some use cases are only solvable with touching the SDP, and web developer must know about offer/answer in the process)

If so, which group is mandating that requirement be part of the web developer's API?

This helps define which group is appropriate to address those kinds of concerns.

-Robin
9 July, 2013 2:04 PM

Could you explain the reasoning behind moving the API discussion to the W3C list while leaving the actual API specification documents as Internet Drafts created and edited by the IETF WG?

 

I’m all for moving the API work (back) to W3C, but we should move all of it, don’t you think?

 

Matthew Kaufman

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, July 9, 2013 8:33 AM
To: rtcweb@ietf.org; public-webrtc@w3.org
Subject: [rtcweb] Locus of API discussion

 

Howdy,

The recent set of API discussions has been spread across both the rtcweb and public-webrtc mailing lists.  That's making it both harder to follow and harder for folks to work out who is saying what under which rules.  The chairs of both groups believe that the right place for the discussion to continue should be public-webrtc.  Please direct follow-ups on this topic to that list.

regards,

Ted Hardie

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
9 July, 2013 11:33 AM
Howdy,

The recent set of API discussions has been spread across both the rtcweb and public-webrtc mailing lists.  That's making it both harder to follow and harder for folks to work out who is saying what under which rules.  The chairs of both groups believe that the right place for the discussion to continue should be public-webrtc.  Please direct follow-ups on this topic to that list.

regards,

Ted Hardie
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--------------080707040203050805030103 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------080707040203050805030103-- --------------080803060801030407060808-- From ekr@rtfm.com Tue Jul 9 13:41:13 2013 Return-Path: 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 171B221E8056 for ; Tue, 9 Jul 2013 13:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 9jdXbcm7vacr for ; Tue, 9 Jul 2013 13:41:07 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id C68DB21E8050 for ; Tue, 9 Jul 2013 13:41:03 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so3302662qeb.13 for ; Tue, 09 Jul 2013 13:41:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=nRlFFOHzXplK+7ez06+iUQlYMJBdvdN7BXrn11qs1eA=; b=jhbMAbSgnzgKu23s4ZXULekpYBev+ICFtF7GZYQvrgzf2dLmCUAmt4EYzRBlOhJsNq wujXfVQ72iVbqm2U1JMASc2zR1fXsSYWAasHdJRCRDEgQ5EIz3nJlKf55k7bVgcqhLp6 eyXJhFfykHsJe94BxPyaAQ+OA8h9f5tnkN7QGoiDjFaHAj/JorW/YDPkpVzfrHYenTMh JYX/F5f2Lu8eDkbu49/POGoDLPE8RFQtMGOUj++0LaRqdszxEUP0RhwQn6Gj72Fqr1cS CKK3mwoVL371tgB2Uu+4ZN90UwrLbO6wPjFqeyw7BZJZeAm8Dw7P0Br0NHK9FyNTH4sh Ncyg== X-Received: by 10.224.5.199 with SMTP id 7mr10292991qaw.87.1373402463263; Tue, 09 Jul 2013 13:41:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Tue, 9 Jul 2013 13:40:23 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <51DC3644.4020107@bbs.darktech.org> References: <51DC3644.4020107@bbs.darktech.org> From: Eric Rescorla Date: Tue, 9 Jul 2013 13:40:23 -0700 Message-ID: To: cowwoc Content-Type: multipart/alternative; boundary=001a11c2e4d4f4ef2e04e11a2df6 X-Gm-Message-State: ALoCoQkkDDyNeHL9se1I+wAZXrSl7kxp9PjU8HfYTQ+/rVxgQ7pEPKsfud3Sj7pCmeX3/s2ybqNG Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 20:41:13 -0000 --001a11c2e4d4f4ef2e04e11a2df6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 9:11 AM, cowwoc wrote: > On 09/07/2013 11:33 AM, Ted Hardie wrote: > >> Howdy, >> >> The recent set of API discussions has been spread across both the rtcweb >> and public-webrtc mailing lists. That's making it both harder to follow >> and harder for folks to work out who is saying what under which rules. The >> chairs of both groups believe that the right place for the discussion to >> continue should be public-webrtc. Please direct follow-ups on this topic >> to that list. >> >> regards, >> >> Ted Hardie >> > Ted, > > I agree, with one caveat: virtually none of the high-level > stakeholders (spec editors, browser vendors, etc) bother to engage the > community on public-webrtc. > I'm not sure I understand this complaint. Is it that the aforementioned "high-level stakeholders" aren't engaging or merely that they are only engaging on RTCWEB? If it's the former, than I don't think that's actually true, since in the past week, you've had responses from (at least) the following people who fall into those categories: Cullen Jennings (spec editor) Adam Bergqvist (spec editor) Peter Thatcher (works on Chrome) Me (works on Firefox and Chrome; spec editor) Christer Holmberg (spec editor) Several people from Microsoft. Who, exactly, are you expecting to engage that hasn't engaged? If your complaint is just that they're engaging on the wrong mailing list, well that seems to reinforce Ted's point above. -Ekr What's the point of discussing the API on this mailing list if our > opinion goes unnoticed? We shouldn't be moving the discussion to > public-webrtc as a nice way to filter us out. This discussion requires > their attention, be it on one mailing list or the other. I don't mind where > we discuss it, so long as they get involved. > > Is it their intention to get involved on public-webrtc and summarize > the results on rtcweb? > > Thanks, > Gili > > --001a11c2e4d4f4ef2e04e11a2df6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 9, 2013 at 9:11 AM, cowwoc <cowwoc@bbs.darktech.= org> wrote:
On 09/07/2013 11:33 AM, Ted Hardie= wrote:
Howdy,

The recent set of API discussions has been spread across both the rtcweb an= d public-webrtc mailing lists. =A0That's making it both harder to follo= w and harder for folks to work out who is saying what under which rules. = =A0The chairs of both groups believe that the right place for the discussio= n to continue should be public-webrtc. =A0Please direct follow-ups on this = topic to that list.

regards,

Ted Hardie
Ted,

=A0 =A0 I agree, with one caveat: virtually none of the high-level stakehol= ders (spec editors, browser vendors, etc) bother to engage the community on= public-webrtc.

I'm not sure I unde= rstand this complaint. Is it that the aforementioned "high-level stake= holders"
aren't engaging or merely that they are only engaging on RTCWEB? I= f it's the former, than
I don't think that's actually= true, since in the past week, you've had responses from (at least)
the following people who fall into those categories:

Cullen Jennings (spec editor)
Adam Bergqvist (spec editor= )
Peter Thatcher (works on Chrome)
Me (works on F= irefox and Chrome; spec editor)
Christer Holmberg (spec editor)
Several people f= rom Microsoft.

Who, exactly, are you e= xpecting to engage that hasn't engaged?=A0


If your complaint is just that they're = engaging on the wrong mailing list, well
that seems to rein= force Ted's point above.

-Ekr




=A0 =A0 What's the point of discussing the API on this mailing list if = our opinion goes unnoticed? We shouldn't be moving the discussion to pu= blic-webrtc as a nice way to filter us out. This discussion requires their = attention, be it on one mailing list or the other. I don't mind where w= e discuss it, so long as they get involved.

=A0 =A0 Is it their intention to get involved on public-webrtc and summariz= e the results on rtcweb?

Thanks,
Gili


--001a11c2e4d4f4ef2e04e11a2df6-- From creslin@digium.com Tue Jul 9 15:00:15 2013 Return-Path: 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 8283521F9A74 for ; Tue, 9 Jul 2013 15:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 tDb3fdLNcYHT for ; Tue, 9 Jul 2013 15:00:09 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4DACC11E8192 for ; Tue, 9 Jul 2013 14:59:03 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id r11so5116712lbv.13 for ; Tue, 09 Jul 2013 14:59:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=0xFTV7yztDaJ8B0VgqrzmgoESrSAGp4dfJYcmK1lDw4=; b=mFTFTpXVC9r5o2v+6vxLIlX9utHahk5tfyMF9FjVTJc5cQiKWugHaErRWOSehH6WEs 9UPmzq7DIMd2ljdSjxhGvc20ulEiHIC+seHlGrDvCazmlbaQ/mzXbWg3bidkbthagrnb IfzDIGwb/y17IYzXWpTHtZClb+PPH5196MsXZa/XZdC4wmN3KKwMfdWCBoJZwsYwEIcI 27LQmD1rCEjkKt4xiH/s24Nsf9BiTYjDQE9POKQtmMorK38YK5/5rEL89W54dbyX9xOi ASlEkF+LE9GnOUmxd7T7zYyxD1p4nHva8oNWLJvVLxfcdWPnwQ1yc6B35uP49YwR4g+K gBFA== MIME-Version: 1.0 X-Received: by 10.112.201.138 with SMTP id ka10mr13614787lbc.72.1373407140530; Tue, 09 Jul 2013 14:59:00 -0700 (PDT) Received: by 10.112.141.161 with HTTP; Tue, 9 Jul 2013 14:59:00 -0700 (PDT) In-Reply-To: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> Date: Tue, 9 Jul 2013 16:59:00 -0500 Message-ID: From: Matt Fredrickson To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11c266bebe5fec04e11b442b X-Gm-Message-State: ALoCoQmG4a6ADBbgalXGDO3Q8WdH9PmdK8nkv/1UjOaCMKJpeQmm7/Cu3UnNXo7wt5qnvsAekVWU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 22:00:15 -0000 --001a11c266bebe5fec04e11b442b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 8, 2013 at 1:15 PM, Justin Uberti wrote: > On Mon, Jul 8, 2013 at 1:52 AM, Muthu Arul Mozhi Perumal (mperumal) < > mperumal@cisco.com> wrote: >> >> 3) There is no text describing how the timestamp encoded in the UNSERNAME >> attribute of the ALLOCAE requested could be protected. >> > > In the HTTP Interactions section, I mention that the password used for the > MESSAGE-INTEGRITY is a digest of the username, but I can make this more > explicit. > Muthu, What situations did you have in mind with regards to timestamp protection that potentially would be vulnerable (beyond any protection the the digest gives)? Matthew Fredrickson --001a11c266bebe5fec04e11b442b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 8, 2013 at 1:15 PM, Justin Uberti <juberti@g= oogle.com> wrote:
=
On Mon, Jul 8, 2013 at 1:52 AM, Muthu Arul Mozhi= Perumal (mperumal) <mperumal@cisco.com> wrote:

3) There is no text describing how the t= imestamp encoded in the UNSERNAME attribute of the ALLOCAE requested could = be protected.

=A0
In the HTTP Interactions section,= I mention that the password used for the MESSAGE-INTEGRITY is a digest of = the username, but I can make this more explicit.

Muthu,

What situa= tions did you have in mind with regards to timestamp protection that potent= ially would be vulnerable (beyond any protection the the digest gives)?

Matthew Fredrickson=A0
--001a11c266bebe5fec04e11b442b-- From juberti@google.com Tue Jul 9 21:40:08 2013 Return-Path: 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 B26EB21F84D4 for ; Tue, 9 Jul 2013 21:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.310, 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 9xWq6txFphtr for ; Tue, 9 Jul 2013 21:40:08 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id E311311E8112 for ; Tue, 9 Jul 2013 21:40:07 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so5890047wib.0 for ; Tue, 09 Jul 2013 21:40:06 -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=LT14DDpnssTVi0/wfNFbCoED7T+rxtLMu6PCYX+iNn4=; b=DJgzVhxUlCxJnc/MsBYMpkkFIGGeS5+rj6EhmZHLRVsCaH1fN7b949T//HJIXI6F6V zjmkolRA+dGxcCp+WNRJTeDRAsYc5rPk6kGdiUC8GzGEi/4BSbfo4W5TTnfBnahNnmg/ I8cZR3+evmPUX7ioW2BOWcKZMJmkkDkTuxyhOmfU7V3JvuD2zbuEs72c87EefM116xCO HZEegqOaPR/y/sPvrjgf7mcfhMwVtVK20Rm+SOQhr9XsJtQxh/0giST78fZXDCYIVjxr 2Yt3xl/s5NVDyBRZldnPbwy6rmNav9QX8zWwrRuR3daZ06oikpWXGu2XxbXOyzNn43lH y+hA== 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=LT14DDpnssTVi0/wfNFbCoED7T+rxtLMu6PCYX+iNn4=; b=m++itLJuk6fgDLXVtsZFwnjLqaTXDQizsCD8BlNFCkSbAmb2N42CJmRsYmpc/ZQWJI mM8GnCpg6DQZuQcFDPl9ecCDQoTNoFSE9PZgHxxtSEurAl31SnFlgmtcTWRkdEtARQ+f ryeazoYtEPJ0PmipLGB3ye8ZLV5MvkznVFklOna5daG1wAk55aUEuixzq+dkOfdpcOaO 524CZ7MutotmyXiBdmfsn3vSU2JTKUj69DG9bE7ntsdcBbkufe0A0QO2mTkHruwPbyRH 1QLppFY8L5paJS7m9sHDLbu98eSbKIjYqh8qxGSqP9GsfJtQbKhdJ3exrjQFS5Ce20ie 4G5Q== X-Received: by 10.180.211.233 with SMTP id nf9mr16070317wic.41.1373431206835; Tue, 09 Jul 2013 21:40:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Tue, 9 Jul 2013 21:39:46 -0700 (PDT) In-Reply-To: <51DB3443.6070301@nostrum.com> References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> <51DB3443.6070301@nostrum.com> From: Justin Uberti Date: Wed, 10 Jul 2013 00:39:46 -0400 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a11c338d035177904e120df12 X-Gm-Message-State: ALoCoQmG+qORyq6vYaIIkV+7gWBNVHAvY3eStGMLFkvwUfybIcttaZpBX2lPsMdYzzzlL85J66QlGNVGFOPUXQaZ9m/DpVP7njFL6Mg8jCXVHxZ2IMOvB8ZfluXyD0aE1PCj7mlpuP6P6GmD2XH85eJ9opgDlkXvdfa8PSONgq3k8h/NwJtPq7XGMPYC0dTbj3kBbTg/8KGr Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 04:40:08 -0000 --001a11c338d035177904e120df12 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 8, 2013 at 5:50 PM, Adam Roach wrote: > On 7/7/13 23:24, Justin Uberti wrote: > >> Just uploaded a 00 version of a spec for requesting time-limited TURN >> credentials for WebRTC apps. Would like to get 10 minutes of agenda time to >> present this in Berlin. >> > > Thanks for getting ball rolling on this, Justin. I agree that this is an > important mechanism to have defined. > > I only find one issue in my initial read through the document: why are we > proposing the use of HTTP POST for stateless, idempotent information > retrieval? The key benefit of this approach is that it doesn't actually > create state in the network. That's a much better fit for GET. > > Compare RFC 2616, sections 9.3 and 9.5, and see if you don't agree. I originally had this as a GET and switched it to a POST for basically the same reasons that Martin outlined - it wasn't completely stateless, and two different requests would return different usernames (because of new timestamps). But if these concerns are overall insignificant, I would be more than happy to switch back to GET. --001a11c338d035177904e120df12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 8, 2013 at 5:50 PM, Adam Roach <adam@nostrum.com>= ; wrote:
On 7/7/13 23:24, Justin Ub= erti wrote:
Just uploaded a 00 version of a spec for requesting time-limited TURN crede= ntials for WebRTC apps. Would like to get 10 minutes of agenda time to pres= ent this in Berlin.

Thanks for getting ball rolling on this, Justin. I agree that this is an im= portant mechanism to have defined.

I only find one issue in my initial read through the document: why are we p= roposing the use of HTTP POST for stateless, idempotent information retriev= al? The key benefit of this approach is that it doesn't actually create= state in the network. That's a much better fit for GET.

Compare RFC 2616, sections 9.3 and 9.5, and see if you don't agree.

I originally had this as a GET and switched it= to a POST for basically the same reasons that Martin outlined - it wasn= 9;t completely stateless, and two different requests would return different= usernames (because of new timestamps). But if these concerns are overall i= nsignificant, I would be more than happy to switch back to GET.

--001a11c338d035177904e120df12-- From denglingli@chinamobile.com Tue Jul 9 23:27:16 2013 Return-Path: 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 10A6021F9DED for ; Tue, 9 Jul 2013 23:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.707 X-Spam-Level: X-Spam-Status: No, score=0.707 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] 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 fLkdrC80mZZz for ; Tue, 9 Jul 2013 23:27:12 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 84FF521F9DE3 for ; Tue, 9 Jul 2013 23:27:11 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee151dcfe7f79f-6779f; Wed, 10 Jul 2013 14:26:07 +0800 (CST) X-RM-TRANSID: 2ee151dcfe7f79f-6779f Received: from cmccPC (unknown[10.2.52.157]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee251dcfe7b809-061d7; Wed, 10 Jul 2013 14:26:07 +0800 (CST) X-RM-TRANSID: 2ee251dcfe7b809-061d7 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: Date: Wed, 10 Jul 2013 14:26:50 +0800 Message-ID: <00bd01ce7d36$7da5b1c0$78f11540$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac57mSt6qQ8mPFsHS8uyRIKqCQgtkQBm3MBg Content-Language: zh-cn Subject: [rtcweb] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-deng-rtcweb-codecapi-00=2Etxt?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 06:27:16 -0000 Hi all, We submitted a new draft proposing to make use of existing codec APIs on = mobile terminals to provide a more cost-effective way of achieving = better interoperability without extra costs for the browser vendors to = re-implement relevant audio/video codecs. It also proposes to add = notifications from the browser to web apps whether or not a codec is = provided by the local platform or not, so that the apps can make an = informed decision on which codec to use in its specific communication = scenario. http://www.ietf.org/internet-drafts/draft-deng-rtcweb-codecapi-00.txt Your comments are welcome. BR Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=888=E6=97=A5 = 12:57 =E6=94=B6=E4=BB=B6=E4=BA=BA: Deng Lingli; Yu Qing; Lingfei Ni; Qing Yu; = Lingli Deng =E4=B8=BB=E9=A2=98: New Version Notification for = draft-deng-rtcweb-codecapi-00.txt A new version of I-D, draft-deng-rtcweb-codecapi-00.txt has been successfully submitted by Lingli Deng and posted to the IETF repository. Filename: draft-deng-rtcweb-codecapi Revision: 00 Title: Proposal for reusing local codec APIs on mobile devices Creation date: 2013-07-08 Group: Individual Submission Number of pages: 5 URL: = http://www.ietf.org/internet-drafts/draft-deng-rtcweb-codecapi-00.txt Status: = http://datatracker.ietf.org/doc/draft-deng-rtcweb-codecapi Htmlized: = http://tools.ietf.org/html/draft-deng-rtcweb-codecapi-00 Abstract: This document proposes the browser to make use of local codec APIs, if available on a mobile device, and notifies RTCWEB applications to allow for better tuning between device capability and media quality. = =20 The IETF Secretariat From mperumal@cisco.com Tue Jul 9 23:40:25 2013 Return-Path: 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 5C69C21F9605 for ; Tue, 9 Jul 2013 23:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 NG99FWiU+nDb for ; Tue, 9 Jul 2013 23:40:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 52F1521F95DD for ; Tue, 9 Jul 2013 23:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7493; q=dns/txt; s=iport; t=1373438419; x=1374648019; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=p2b8WbCUlYJBKCdD1ux8lknlo/HSGoeNQsfDnS3pTvA=; b=j7R2v6vM8sOEMzNYU3t1RxXPIZvAH9yZfxIHbWdvDxHuOYbZroO9Itu6 08XipLqoVLvoHDpjaHt+WHsWTN2vjfaf4WM7nn5XqLvHTbHiHIMlvszCj M5EIb/cHx5FbhhHpnEleq5XPplRqH2cdZMfuPgQj+aupfAsiSjn+vgKDD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAG4A3VGtJV2Z/2dsb2JhbABagkVEMk3BDIEQFnSCIwEBAQQtSgIQAgEIDgMEAQELDg8HMhQJCAIEAQ0FCIgHuSCPOjEGAQYSgnFrA6kdgViBOYIo X-IronPort-AV: E=Sophos;i="4.87,1033,1363132800"; d="scan'208,217";a="232895347" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 10 Jul 2013 06:40:18 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6A6eIVf015060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 06:40:18 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 10 Jul 2013 01:40:18 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Matt Fredrickson , Justin Uberti Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt Thread-Index: AQHOfO+HUNp8rVA2Hk+r7n9ToQFYGJlddWcg Date: Wed, 10 Jul 2013 06:40:17 +0000 Message-ID: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.211.93] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE224189868xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 06:40:25 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE224189868xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable |What situations did you have in mind with regards to timestamp protection |that potentially would be vulnerable (beyond any protection the the digest |gives)? I think the digest protection should suffice for all practical purposes. On= the other hand, is the web and TURN server clocks expected to be in sync? = I think the draft should discuss it. Muthu From: Matt Fredrickson [mailto:creslin@digium.com] Sent: Wednesday, July 10, 2013 3:29 AM To: Justin Uberti Cc: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb= -turn-rest-00.txt On Mon, Jul 8, 2013 at 1:15 PM, Justin Uberti > wrote: On Mon, Jul 8, 2013 at 1:52 AM, Muthu Arul Mozhi Perumal (mperumal) > wrote: 3) There is no text describing how the timestamp encoded in the UNSERNAME a= ttribute of the ALLOCAE requested could be protected. In the HTTP Interactions section, I mention that the password used for the = MESSAGE-INTEGRITY is a digest of the username, but I can make this more exp= licit. Muthu, What situations did you have in mind with regards to timestamp protection t= hat potentially would be vulnerable (beyond any protection the the digest g= ives)? Matthew Fredrickson --_000_E721D8C6A2E1544DB2DEBC313AF54DE224189868xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

|What situations did you have in mind wi= th regards to timestamp protection

|that potentially would be vulnerable (b= eyond any protection the the digest

|gives)?

 

I think the digest protection should suf= fice for all practical purposes. On the other hand, is the web and TURN ser= ver clocks expected to be in sync? I think the draft should discuss it.

 

Muthu

 

From: Matt Fre= drickson [mailto:creslin@digium.com]
Sent: Wednesday, July 10, 2013 3:29 AM
To: Justin Uberti
Cc: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti= -rtcweb-turn-rest-00.txt

 

On Mon, Jul 8, 2013 at 1:15 PM, Justin Uberti <juberti@google.com> wrote:

On Mon, Jul 8, 2013 at 1:52 AM, Muthu Arul Mozhi Per= umal (mperumal) <mperumal@cisco.com> wrote:

3) There is no text describing how the timestamp encod= ed in the UNSERNAME attribute of the ALLOCAE requested could be protected.

 

In the HTTP Interactions section, I mention that the= password used for the MESSAGE-INTEGRITY is a digest of the username, but I= can make this more explicit.

 

Muthu,

 

What situations did you have in mind with regards to= timestamp protection that potentially would be vulnerable (beyond any prot= ection the the digest gives)?

 

Matthew Fredrickson 

--_000_E721D8C6A2E1544DB2DEBC313AF54DE224189868xmbrcdx02ciscoc_-- From cowwoc@bbs.darktech.org Tue Jul 9 09:12:57 2013 Return-Path: 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 2930B21F9E1E for ; Tue, 9 Jul 2013 09:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.986 X-Spam-Level: X-Spam-Status: No, score=-6.986 tagged_above=-999 required=5 tests=[AWL=-3.387, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 jWkWK9hEusud for ; Tue, 9 Jul 2013 09:12:51 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 459D021F9C68 for ; Tue, 9 Jul 2013 09:12:51 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l10so8077715oag.17 for ; Tue, 09 Jul 2013 09:12:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=X6JUH9ZoAprBjNSDWZyT3Faom6FUdALcio/0eJzL0rQ=; b=b0d5bO4fWsYTWUAJezWtuwc8EZVLZIyYTkZfwNtfleUV4yf9+B9mMdgOpxhGxbVpfH ue2owg1U3Dkohy9djb8pU2y+HIbK/EMeMZivrnyxbhfPMB8ZaZOWX8M5zvNV+2jp31Q0 3tf3LiLIajneYXAmJ9DaWJITBfrKDRj1aHnhfQCPddovS4RXq0vHYgXpZPksO55Mwrp1 DduUIVAHXR3GBvVAFBjZyBngdba0nWjXk+MxadTd3vwi8vTCh8JQiBiJy041SxDbxrlR /BttkJlqfnuCC1tg0tn+SgJSAbl82/+isYHwIi4J9QWRbtpsRFdKly7hEkVFejC66RKB Va9Q== X-Received: by 10.182.186.66 with SMTP id fi2mr24863216obc.98.1373386369610; Tue, 09 Jul 2013 09:12:49 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id g1sm39474084oeq.6.2013.07.09.09.12.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 09:12:48 -0700 (PDT) Message-ID: <51DC3644.4020107@bbs.darktech.org> Date: Tue, 09 Jul 2013 12:11:48 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org, public-webrtc@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkLVx//ys4IEuOmMA9BM41nTvybMvfZ4AdvoFyVd3g21mnvvtLoLMhyh2aYfUeSsqRqtsaP X-Mailman-Approved-At: Wed, 10 Jul 2013 00:34:00 -0700 Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:13:41 -0000 On 09/07/2013 11:33 AM, Ted Hardie wrote: > Howdy, > > The recent set of API discussions has been spread across both the > rtcweb and public-webrtc mailing lists. That's making it both harder > to follow and harder for folks to work out who is saying what under > which rules. The chairs of both groups believe that the right place > for the discussion to continue should be public-webrtc. Please direct > follow-ups on this topic to that list. > > regards, > > Ted Hardie Ted, I agree, with one caveat: virtually none of the high-level stakeholders (spec editors, browser vendors, etc) bother to engage the community on public-webrtc. What's the point of discussing the API on this mailing list if our opinion goes unnoticed? We shouldn't be moving the discussion to public-webrtc as a nice way to filter us out. This discussion requires their attention, be it on one mailing list or the other. I don't mind where we discuss it, so long as they get involved. Is it their intention to get involved on public-webrtc and summarize the results on rtcweb? Thanks, Gili From cowwoc@bbs.darktech.org Tue Jul 9 10:30:08 2013 Return-Path: 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 A01D821F8FE5 for ; Tue, 9 Jul 2013 10:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=-2.695, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 xuxmMZr5IgGG for ; Tue, 9 Jul 2013 10:30:02 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5F321F9F5E for ; Tue, 9 Jul 2013 10:30:02 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so8357965oag.32 for ; Tue, 09 Jul 2013 10:30:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=Z7kZbV6OsPogIbpqX/eTL5FMRoWN3QkzxD8agmvFAPQ=; b=BkxxyTUg55dqYOIc6pt0wI0eR4oIvcA/Wf2F01xSU1oFpgWoLEiHt268N2fbB6rXuX 23lsfi/6tQ9NM9/l4/fFSi8z2aCWYz/xYOjUfChe90aaJjE2ifos0lsoWf76hejIWYlF MTHOyoWLxhmd3LxE2eGFFROev2syHK+cS7KnuKjVEQriVfARo8pUqMh2F4+1Hpypkgfz 4pENq6qWMlqIITANw3uw/kmhKuIRwNGXYBbR9/kaRVIL9CT8oN5HgNY6+RgjH3dZXr8v jNwKmdRc/KgK+o5hRJ2jamIcuzdwhnLl6O21S4cLzBPuS/HAMv/1pPoEXHFbcfFJdYyL pbiQ== X-Received: by 10.60.56.229 with SMTP id d5mr24896772oeq.7.1373391001882; Tue, 09 Jul 2013 10:30:01 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id b7sm39124213oby.5.2013.07.09.10.29.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 10:30:01 -0700 (PDT) Message-ID: <51DC485B.8060507@bbs.darktech.org> Date: Tue, 09 Jul 2013 13:28:59 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51DC3644.4020107@bbs.darktech.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkfBYZiZZ+CNGvXh1cBSDAxuVfN84YR0eNesYqJS6AiGqo6ipXJ8LzqSDT7SBTVHT//yaOS X-Mailman-Approved-At: Wed, 10 Jul 2013 00:34:00 -0700 Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 17:30:08 -0000 On 09/07/2013 1:26 PM, Bjoern Hoehrmann wrote: > * cowwoc wrote: >> I agree, with one caveat: virtually none of the high-level >> stakeholders (spec editors, browser vendors, etc) bother to engage the >> community on public-webrtc. > W3C's Web Real-Time Communications Working Group is required to address > all feedback it receives in a timely and technically sound manner. Take > http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0081 > up Anne van Kesteren's offer to help if that is not working out for you. Glad to hear it. Thanks! I look forward to hearing their feedback. Gili From cowwoc@bbs.darktech.org Tue Jul 9 14:45:46 2013 Return-Path: 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 28B5111E8164 for ; Tue, 9 Jul 2013 14:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=-2.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bGs98dZUEf5L for ; Tue, 9 Jul 2013 14:45:40 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 42F5911E8156 for ; Tue, 9 Jul 2013 14:45:40 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so8703761oag.16 for ; Tue, 09 Jul 2013 14:45:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=yOyadvBCXYRfvHPGkPjbVi7OEiF/8Zep0dFl0P44+6c=; b=GeTm+IZtbmz2I7xZTrhupHYeMHzL0/Hy8MfQCzuvmlMPQmqHmF+ctqwNxnlOLGrvV7 2a2gvOhSYC0a4PnV049m0LDt9Cu7iRThLHSwHjd/m6YRbP2IX3OkLumuyeY18Lhw3wN7 gcMB2OdbXyf9M/rW3vJd4YdnZRzhZDwP3Y781OZZ5l6xVQbaC6erBfyzsvlyRdnkdXSC 2rvhqzlz9o1cnQeI6sb3yzlKB9Q5+dJsTtIkBHooTG/0zox1m91tgR/gffdv4oXzAT33 Su+bK8zR3ax8iSSy6RDo14ByEFhzg+onZlhlly/NHVbQIrIujljktXfLJ0962j6LefXg n/iA== X-Received: by 10.182.214.39 with SMTP id nx7mr25883972obc.20.1373406339538; Tue, 09 Jul 2013 14:45:39 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ps5sm40984235oeb.8.2013.07.09.14.45.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 14:45:38 -0700 (PDT) Message-ID: <51DC8445.2030902@bbs.darktech.org> Date: Tue, 09 Jul 2013 17:44:37 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eric Rescorla References: <51DC3644.4020107@bbs.darktech.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlrB01kq96j/DrebHFHzkaTzmRD6SSDiGPLFY637bSxFQhi2+v2xyU4X+JXHyRKoRgFsvP7 X-Mailman-Approved-At: Wed, 10 Jul 2013 00:34:00 -0700 Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 21:45:46 -0000 On 09/07/2013 4:40 PM, Eric Rescorla wrote: > I'm not sure I understand this complaint. Is it that the > aforementioned "high-level stakeholders" > aren't engaging or merely that they are only engaging on RTCWEB? If > it's the former, than > I don't think that's actually true, since in the past week, you've had > responses from (at least) > the following people who fall into those categories: > > Cullen Jennings (spec editor) > Adam Bergqvist (spec editor) > Peter Thatcher (works on Chrome) > Me (works on Firefox and Chrome; spec editor) > Christer Holmberg (spec editor) > Several people from Microsoft. > > Who, exactly, are you expecting to engage that hasn't engaged? > Hi Eric, It's my understanding that public-webrtc is for discussing the WebRTC API, and RTCWeb is for discussing the WebRTC wire protocol. Three weeks ago I posted a summary of discussion points that came up in the WebRTC World conference (most of which had to do with the WebRTC API). To date, I have not received a reply from any of the people you have listed. I am unable to gather the necessary momentum to turn these points into action items without your help. I was/am frustrated that the spec editors and vendors are responsible to engage the community on these matters, but did not. I hope this clarifies what I meant. On a side-note, I do not view the SDP discussion as a response to my post. This discussion was well under-way beforehand and only made up one of the seven points I brought up. I would appreciate it if multiple stakeholders would address each of the points I brought up. > If your complaint is just that they're engaging on the wrong mailing > list, well > that seems to reinforce Ted's point above. That's fine. I don't mind moving all API discussion to this list, so long as they actually reply this time. Thank you, Gili From rachel.huang@huawei.com Wed Jul 10 02:42:33 2013 Return-Path: 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 410A021F9F2D; Wed, 10 Jul 2013 02:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 44BQaLmDI690; Wed, 10 Jul 2013 02:42:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 91E1421F9F26; Wed, 10 Jul 2013 02:42:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATH47940; Wed, 10 Jul 2013 09:42:20 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Jul 2013 10:41:38 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Jul 2013 10:42:10 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Wed, 10 Jul 2013 17:42:04 +0800 From: "Huangyihong (Rachel)" To: "'xrblock'" , "rtcweb@ietf.org" Thread-Topic: [xrblock][rtcweb]FW: New Version Notification for draft-huang-xrblock-rtcweb-rtcp-xr-metrics-01.txt Thread-Index: AQHOfVG7xwmcLZVirU6X/3aUe04P2w== Date: Wed, 10 Jul 2013 09:42:03 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB45840DD7@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [rtcweb] [xrblock]FW: New Version Notification for draft-huang-xrblock-rtcweb-rtcp-xr-metrics-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 09:42:33 -0000 SGkgYWxsLCANCg0KV2UganVzdCB1cGxvYWRlZCBhIG5ldyBkcmFmdCB0byBkaXNjdXNzIHNvbWUg cnRjcCB4ciBtZXRyaWNzIHdoaWNoIG1heSBiZSB1c2VmdWwgZm9yIFdlYlJUQyBzdGF0aXN0aWNz IEFQSXMuIFlvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSBoaWdobHkgYXBwcmVjaWF0 ZWQuDQoNCkJlc3QgcmVnYXJkcywNClJhY2hlbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDEwLCAyMDEzIDU6MjcgUE0NClRv OiBWYXJ1biBTaW5naDsgSHVhbmd5aWhvbmcgKFJhY2hlbCk7IFJvbmkgRXZlbg0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odWFuZy14cmJsb2NrLXJ0Y3dlYi1y dGNwLXhyLW1ldHJpY3MtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1 YW5nLXhyYmxvY2stcnRjd2ViLXJ0Y3AteHItbWV0cmljcy0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgUmFjaGVsIEh1YW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaHVhbmcteHJibG9jay1ydGN3ZWItcnRj cC14ci1tZXRyaWNzDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBDb25zaWRlcmF0aW9uIGZvciBT ZWxlY3RpbmcgUlRDUCBFeHRlbmRlZCBSZXBvcnQgKFhSKSBNZXRyaWNzIGZvciBSVENXRUIgU3Rh dGlzdGljcyBBUEkNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTEwDQpHcm91cDoJCSBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTINClVSTDogICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVhbmcteHJibG9jay1ydGN3 ZWItcnRjcC14ci1tZXRyaWNzLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1YW5nLXhyYmxvY2stcnRjd2ViLXJ0Y3AteHItbWV0 cmljcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o dWFuZy14cmJsb2NrLXJ0Y3dlYi1ydGNwLXhyLW1ldHJpY3MtMDENCkRpZmY6ICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaHVhbmcteHJibG9jay1ydGN3 ZWItcnRjcC14ci1tZXRyaWNzLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgbW9uaXRvcmluZyBmZWF0dXJlcyByZWxhdGVkIHRvIFJUQ1dFQi4gSXQNCiAgIHByb3Zp ZGVzIGEgbGlzdCBvZiBSVENQIFhSIG1ldHJpY3MgdGhhdCBhcmUgdXNlZnVsIGFuZCBtYXkgbmVl ZCB0byBiZQ0KICAgc3VwcG9ydGVkIGluIHNvbWUgUlRDV0VCIGltcGxlbWVudGF0aW9ucy4NCg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From andrew.hutton@siemens-enterprise.com Wed Jul 10 07:00:21 2013 Return-Path: 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 CFCA221F9F2E for ; Wed, 10 Jul 2013 07:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, 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 zYJyFxNmeqAp for ; Wed, 10 Jul 2013 07:00:17 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9131221F9F00 for ; Wed, 10 Jul 2013 07:00:13 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 61BB81EB8690; Wed, 10 Jul 2013 16:00:10 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Wed, 10 Jul 2013 16:00:10 +0200 From: "Hutton, Andrew" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , "rt >> \"rtcweb@ietf.org\"" Thread-Topic: draft-ietf-rtcweb-use-cases-and-requirements - HTTP Only Firewall. Thread-Index: AQHOcxH6LsByzdb3v06Hk4dVDiPxEJleAv9Q Date: Wed, 10 Jul 2013 14:00:08 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1163B018@MCHP04MSX.global-ad.net> References: <20130627084022.19251.22430.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B1C306ECD@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C306ECD@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements - HTTP Only Firewall. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:00:22 -0000 Hi, Regarding the use case in 3.2.3 covering a HTTP only FW the text states: "This use-case is almost identical to the Simple Video Communication Servic= e use-case (Section 3.2.1). The difference is that one of the users is beh= ind a FW that only allows http traffic". This needs to be changed to allow for the common case when a HTTP Proxy is = deployed so I suggest changing the last sentence to "The difference is that one of the users is behind a FW that only allows tr= affic via a HTTP Proxy". There also needs to be a corresponding change to requirement F37. I believe we have previously discussed changing this but have to admit I co= uld not fine the e-mail chain so maybe it was during a meeting. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Stefan H=E5kansson LK > Sent: 27 June 2013 09:50 > To: rt >> "rtcweb@ietf.org" > Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb- > use-cases-and-requirements-11.txt >=20 > From the change log: >=20 > o Described that the API requirements are really from a W3C > perspective and are supplied as an appendix in the introduction. > Moved API requirements to an Appendix. >=20 > o Removed the "Conventions" section with the key-words and > reference > to RFC2119. Also changed uppercase MUST's/SHOULD's to > lowercase. >=20 > o Added a note on the proposed use of the document to the > introduction. >=20 > o Removed the note talking about WS from the "FW that only allows > http" use-case. >=20 > o Removed the word "Skype" that was used as example in one of the > use-cases. >=20 > o Clarified F3 (the req saying the everything the browser sends > must > be rate controlled). >=20 > o Removed the TBD saying we need to define reasonable levels from > the requirement saying that quality must be good even in > presence > of packet losses (F5), and changed "must" to "should" (Based on > a > list discussion involving Bernard). >=20 > o Removed F6 ("The browser must be able to handle high loss and > jitter levels in a graceful way."), also after a list > discussion. >=20 > o Clarified F7 (used to say that the browser must support fast > stream switches, now says that reference frames must be inserted > when requested). > o Removed the questions from F9 (echo cancellation), F10 > (syncronization), F21 (telephony codec). >=20 > o Exchanged "restrictive firewalls" for "limited middleboxes" in > F19 > (as proposed by Martin). >=20 > o Expanded DTMF and IVR in F22 (proposed by Martin) >=20 > o Added ref to RFC5405 in F23 (proposed by Lars Eggert). >=20 > o Exchanged "service provided" for "web application" in F32. >=20 > o Changed the text in 3.2.1 that motivates F36 (new text "It is > essential that media and data be encrypted, authenticated ... > bound to the user identity."); and rewrote F36, included a ref > to > RFC5479. >=20 > o Changed "quality of service" to "quality of experience" in F38. >=20 > o Added F39. >=20 > o Used new formulation of A17 (proposed by Martin). >=20 > o Updated A20. >=20 > o Updated A25. >=20 > Things that have not been done: >=20 > - No use-case on emergency services added (as said already in > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07253.html) >=20 > - No use-case on real-time text added (as said already in > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07254.html) >=20 > - No clarification on what solution(s) related to multiple resolutions > of the same content added (discussed in > http://www.ietf.org/mail-archive/web/rtcweb/current/msg07256.html but > no > input received). >=20 > - The order of the requirements (Fn) is still a mess - but I kept it as > is for this version to make diffing simpler. To be fixed in an upcoming > version. >=20 > Stefan >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-ietf-rtcweb-use-cases-and-requirements-11.txt > Date: 10:40 > From: internet-drafts@ietf.org > To: Christer Holmberg , G=F6ran > Eriksson AP , Stefan H=E5kansson LK > , G=F6ran Eriksson AP > >=20 >=20 > A new version of I-D, draft-ietf-rtcweb-use-cases-and-requirements- > 11.txt > has been successfully submitted by Christer Holmberg and posted to the > IETF repository. >=20 > Filename: draft-ietf-rtcweb-use-cases-and-requirements > Revision: 11 > Title: Web Real-Time Communication Use-cases and > Requirements > Creation date: 2013-06-27 > Group: rtcweb > Number of pages: 30 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and- > requirements-11.txt > Status: > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and- > requirements > Htmlized: > http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and- > requirements-11 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-use-cases-and- > requirements-11 >=20 > Abstract: > This document describes web based real-time communication use- > cases. > Requirements on the browser functionality are derived from use- > cases. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From creslin@digium.com Wed Jul 10 08:11:54 2013 Return-Path: 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 C736221F9D12 for ; Wed, 10 Jul 2013 08:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 HUCBoppVNtce for ; Wed, 10 Jul 2013 08:11:49 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6E16B21F9B07 for ; Wed, 10 Jul 2013 08:11:49 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id 10so5695184lbf.8 for ; Wed, 10 Jul 2013 08:11:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hAJnLlCrCwwStD8RnY06J35ct/VpSNg5qm8E+372a1s=; b=fOsH52XVlatyvH50CCgiEd0kAb97xkNk+QLFDjPLAXgpZ4g9b1/FGHOixrKXVY7Udj YhOo0ChTyh0r5YvMgAvMuMFtyS5YkKb5aMtec3JEbRGOm56ufuGDCd4Gl9TgRKw18eCM 4gWXNxQCeFc/sLoYhxyGiaZb7nadETqqvvlROjz4qwP0a1l8mBoVSKdPK3YxPRSt87n8 Rayhkh/qnF+FBxSXfaranJWIEsembMUOfDGJUzNmar45Z3qrBWA/ONCnuWVMOuP7es69 7Jk8Md6ANc9ba+KWl7AtiUXDyJwlSETlT5DZ4rRfCG21YbAjfhIm9aluBeAStXwIc20U koMw== MIME-Version: 1.0 X-Received: by 10.152.19.40 with SMTP id b8mr15078580lae.34.1373469107884; Wed, 10 Jul 2013 08:11:47 -0700 (PDT) Received: by 10.112.141.161 with HTTP; Wed, 10 Jul 2013 08:11:47 -0700 (PDT) In-Reply-To: References: <20130708041540.7930.93762.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 10:11:47 -0500 Message-ID: From: Matt Fredrickson To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=089e01493b1649263f04e129b2b5 X-Gm-Message-State: ALoCoQkH5RT4aPyjRdCn8zjyUWEnOIefBAUg7jInsNZy7GFxBmPkplLWE7AaiEXadc7OLWQ+1jeJ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 15:11:54 -0000 --089e01493b1649263f04e129b2b5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 1:40 AM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > I think the digest protection should suffice for all practical purposes. > On the other hand, is the web and TURN server clocks expected to be in > sync? I think the draft should discuss it. > I tend to agree as well. Just from an implementation perspective, it seems like that a presumed current timestamp on the credentials could be useful for TTLs on the credentials. It seems that this also could be a potential security vulnerability if the time was out of sync between the two servers. Matthew Fredrickson --089e01493b1649263f04e129b2b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2013 at 1:40 AM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> wrote:

I think the digest protection sho= uld suffice for all practical purposes. On the other hand, is the web and T= URN server clocks expected to be in sync? I think the draft should discuss it.


I tend to agr= ee as well. =A0Just from an implementation perspective, it seems like that = a presumed current timestamp on the credentials could be useful for TTLs on= the credentials. =A0It seems that this also could be a potential security = vulnerability if the time was out of sync between the two servers.

Matthew Fredrickson
--089e01493b1649263f04e129b2b5-- From eckert@cisco.com Wed Jul 10 11:02:34 2013 Return-Path: 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 A863921F9D50; Wed, 10 Jul 2013 11:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.487 X-Spam-Level: X-Spam-Status: No, score=-10.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 jHCH52Ixpan8; Wed, 10 Jul 2013 11:02:30 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 39CE921F9DBC; Wed, 10 Jul 2013 11:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4297; q=dns/txt; s=iport; t=1373479350; x=1374688950; h=date:from:to:subject:message-id:mime-version; bh=4Krnakf2c8xhkFVZQbRn1doD4IUXOzkoPjHFhN9iwgA=; b=R8fvfXei5wYryAYq4/WluL2Lv8z2e3SARqJckvk5pxEivA28wqXSNDRz xdH07wdrnQkCDjhhcse4zdm2N1g5GmY8JZHKQQVHbpGfWKxLQExb/wsDH 90+AqnA62aqy6PYvs0IPhSZfBinWfwpPZ/acgoHJrrks+l2MFSTEhm4hs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAE+g3VGrRDoG/2dsb2JhbABagwkywWyBExZ0giMBAQE+KyAgAQMBAQEJGgQWBTIDBg8SCYgFDbdjj3CDA2wDiSWOMQGBKZAhgViBWRw X-IronPort-AV: E=Sophos;i="4.87,1037,1363132800"; d="scan'208";a="82622009" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 10 Jul 2013 18:01:48 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6AI1lK7023862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jul 2013 18:01:47 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r6AI1lCI001615; Wed, 10 Jul 2013 11:01:47 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r6AI1lVi001614; Wed, 10 Jul 2013 11:01:47 -0700 Date: Wed, 10 Jul 2013 11:01:47 -0700 From: "Toerless Eckert (eckert)" To: tsvwg@ietf.org, rtcweb@ietf.org, rmcat@ietf.org Message-ID: <20130710180147.GA614@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: [rtcweb] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 18:02:34 -0000 When dealing with congestion for real-time datagram (UDP/RTP) based video flows, one idea that we think has shown to provide good value is to intelligently drop in the network preferentially the least important packets within a video flow, for example non-referenced P-frames, because their loss creates the lowest impact to video quality. One of the main concerns raised against such schemes was one of fairness. If flows would start to indicate different priorities for packets in them, how would we be able to avoid that flows would indicate all their packets to be of high priority to shift packet drops to other flows. Or even more importantly: how could we motivate flows to indicate that some of their packets are low priority without them having to fear that they would experience more loss than than flows that don't do this. So, there is one draft that we would like to present (presumably in TSVWG) explaining how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.txt (Actually, this is how we did solve the problem in our implementatin of intelligent dropping, so this is not theoretical). Now granted, the problem of fairness is but one element of building a complete ssytem around the idea of intelligent dropping, so if folks here on the lists would like to see for example a) how well can it work in routers to shift packet drops to low-prio packets b) whats the evidence that it's good for video quality c) How should we do the marking best going forward Then please let us know. We'd be very interested to provide insight into the parts of those pieces that we have also worked out or discuss the ones we have not (primarily c ;-) Thanks! Toerless In-Reply-To: On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: > Hi all, > > We have submitted a new Internet draft to describe a Normalization Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of NM deployment is to create a new incentive for video encoders to generate more discardable packets when using AF PHB in DIffServ. We are looking forward to your review comments. > > Best regards, > CJ > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, February 08, 2013 6:25 PM > To: Cheng-Jia Lai (chelai) > Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); Fred Yip (fyip) > Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt > > > A new version of I-D, draft-lai-tsvwg-normalizer-00.txt > has been successfully submitted by Cheng-Jia Lai and posted to the > IETF repository. > > Filename: draft-lai-tsvwg-normalizer > Revision: 00 > Title: Normalization Marker for AF PHB Group in DiffServ > Creation date: 2013-02-08 > WG ID: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt > Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer > Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 > > > Abstract: > This memo describes a Normalization Marker (NM) at DiffServ (DS) > nodes to normalize the distribution of DS codepoint (DSCP) markings > for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is > useful for traffic conditioning with Active Queue Management (AQM) > when the AF PHB group is deployed for multimedia service classes that > carry video packets with advanced codec technologies. Using NM can > offer an incentive that is however missing in today's ecosystem of > practical deployment, i.e., when congestion occurs in the AF PHB > group, the network should allow a video codec to benefit from its > effort of generating finer layers of intra-flow precedence (IFP) with > discardable packets in a more balanced distribution. > > > > > The IETF Secretariat > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From dave.taht@gmail.com Wed Jul 10 12:03:08 2013 Return-Path: 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 0BB3011E811D; Wed, 10 Jul 2013 12:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, 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 dj2XaG2g3PCb; Wed, 10 Jul 2013 12:03:05 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1886621F8445; Wed, 10 Jul 2013 12:02:27 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so16421513iej.1 for ; Wed, 10 Jul 2013 12:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3AlDLwTsx/AR+UkecOj/78vM/vAMlo2qsmB0zV/5P3Y=; b=xlLYEYs2XohMvUWfjsYjDE+k63d6G1E291HK/KTlEdHQk70SdapINQxwYdl7mUenHd /iIAzwZIv/P/c/FsdG1AV9r+DZtllC3zDXj4XfL3NF3AyR2KAEuLChCoJwVdD11XFoc4 VFYVyvg6LfLNcwv4EKrXRLQG27Mn7eM1+vmD1KxUJAvVndz6DBDbibcdg7/z0QxuaJ6c oan4kuvxbIetee9UWg05MEXh4Os9fzSVnGj1fV6wf3f+/Sri5DDWF7R22dAFWApn4vcF 1tLAJo6Om1zBIQYoe0TRUbc83G2btqtWx6JSjH2dS6kgmNBmYsi43eR9Kvf2k9SSiEVN 6Zsg== MIME-Version: 1.0 X-Received: by 10.42.133.66 with SMTP id g2mr10511733ict.49.1373482946633; Wed, 10 Jul 2013 12:02:26 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Wed, 10 Jul 2013 12:02:26 -0700 (PDT) In-Reply-To: <20130710180147.GA614@cisco.com> References: <20130710180147.GA614@cisco.com> Date: Wed, 10 Jul 2013 12:02:26 -0700 Message-ID: From: Dave Taht To: "Toerless Eckert (eckert)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 10 Jul 2013 13:37:11 -0700 Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:03:08 -0000 On Wed, Jul 10, 2013 at 11:01 AM, Toerless Eckert (eckert) wrote: > When dealing with congestion for real-time datagram (UDP/RTP) based video= flows, one idea > that we think has shown to provide good value is to intelligently drop in= the network > preferentially the least important packets within a video flow, for examp= le non-referenced > P-frames, because their loss creates the lowest impact to video quality. I've begun to look at webrtc of late in the context of fq_codel. One thing that might work would be ECN marking important frames and not ECN marking others. Problem overall is that ecn can be gamed and is largely not enabled, and so on... > One of the main concerns raised against such schemes was one of fairness.= If flows > would start to indicate different priorities for packets in them, how wou= ld we > be able to avoid that flows would indicate all their packets to be of hig= h priority > to shift packet drops to other flows. Or even more importantly: how could= we motivate > flows to indicate that some of their packets are low priority without the= m having to > fear that they would experience more loss than than flows that don't do t= his. same gaming problem... > So, there is one draft that we would like to present (presumably in TSVWG= ) explaining > how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.tx= t > > (Actually, this is how we did solve the problem in our implementatin of i= ntelligent dropping, > so this is not theoretical). In the case of the fq_codel algorithm I can see a "delayed drop" mechanism happening, where upon deciding to drop, it could defer a drop up to a few packets based on the classification of the packet, say 3 packets at most. Since flows are already identified, this is kind of easy by adding another state variable... At the moment what I have deployed and tested most is a simple 3 tier fq_codel based shaper, which has a priority, best effort, and background queue. The priority queue is generally only DNS traffic, the background is only CS1, and fq_codel does such a good job with sparse streams in the general case that for VOIP, etc on the networks I fiddle with, there is no point in having much more than the BE queue. And presently all other markings are ignored. video is another story. (or could be, I don't know enough about webrtc's behaviors to "see" what will happen) So I can see trying to utilize the AF markings as you describe in your draft in codel's drop decision. While this is also subject to being gamed, the disincentives are slight. This is a little different from using "drop probability" as the decider, however, but I would hope that this mapping of the old AF style random drop ideas into the new style delay ideas could work... And what codel depends on is a definition of "TCP friendly". That if a stream is not going to behave in a tcp friendly manner, then an entirely different strategy for such flows seems necessary, and glomming on some additional state isn't going to be the right thing. > Now granted, the problem of fairness is but one element of building a com= plete ssytem > around the idea of intelligent dropping, so if folks here on the lists wo= uld like to > see for example > > a) how well can it work in routers to shift packet drops to low-prio pa= ckets I guess where I fall apart here is how to shift the encoders to send thinne= r streams at any level of packet drop. > b) whats the evidence that it's good for video quality > c) How should we do the marking best going forward > Then please let us know. We'd be very interested to provide insight into = the parts of > those pieces that we have also worked out or discuss the ones we have not= (primarily c ;-) I'd be interested in specific codecs, example video streams, and test scripts to try and fiddle with this, as well as viable metrics. > > Thanks! > Toerless > > In-Reply-To: > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: >> Hi all, >> >> We have submitted a new Internet draft to describe a Normalization Marke= r (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of = NM deployment is to create a new incentive for video encoders to generate m= ore discardable packets when using AF PHB in DIffServ. We are looking forwa= rd to your review comments. >> >> Best regards, >> CJ >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, February 08, 2013 6:25 PM >> To: Cheng-Jia Lai (chelai) >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert= ); Fred Yip (fyip) >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt >> >> >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >> has been successfully submitted by Cheng-Jia Lai and posted to the >> IETF repository. >> >> Filename: draft-lai-tsvwg-normalizer >> Revision: 00 >> Title: Normalization Marker for AF PHB Group in DiffServ >> Creation date: 2013-02-08 >> WG ID: Individual Submission >> Number of pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-nor= malizer-00.txt >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normali= zer >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-0= 0 >> >> >> Abstract: >> This memo describes a Normalization Marker (NM) at DiffServ (DS) >> nodes to normalize the distribution of DS codepoint (DSCP) markings >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is >> useful for traffic conditioning with Active Queue Management (AQM) >> when the AF PHB group is deployed for multimedia service classes that >> carry video packets with advanced codec technologies. Using NM can >> offer an incentive that is however missing in today's ecosystem of >> practical deployment, i.e., when congestion occurs in the AF PHB >> group, the network should allow a video codec to benefit from its >> effort of generating finer layers of intra-flow precedence (IFP) with >> discardable packets in a more balanced distribution. >> >> >> >> >> The IETF Secretariat >> > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From chelai@cisco.com Wed Jul 10 16:43:00 2013 Return-Path: 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 6D04D11E814E; Wed, 10 Jul 2013 16:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 kYnkvpgVEuWp; Wed, 10 Jul 2013 16:42:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEB121F9B38; Wed, 10 Jul 2013 16:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8199; q=dns/txt; s=iport; t=1373499775; x=1374709375; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JD1mJnu2lnchGEMAxov2z+JrzktK+Y27xua2GBg46/Y=; b=g4C/OCFf3raKEiTQ04BzB1ks6Jnar3d59EIWMZsGaO6NbD4+fSzC/qZF jSQduEJqhNe1IW6ovcndB0AjabDx6N3HzRK8bXU+d2InvDf9N6R3p/YOm UfL7I6V8K7dx5aF5bA6ajFrU2ZPGwlDc1u8u4nXjd8noXG2gEB4tbUDE8 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAOXw3VGtJV2b/2dsb2JhbABagwkyTcEngQ4WdIIjAQEBAQIBZRQFBwQCAQgRAQMBAQEKAhcEBzIUAwYIAgQBDQEECAGIAAYMt16PMgYrAgUGgwNsA4hvkBSQIYFYgTmCKA X-IronPort-AV: E=Sophos;i="4.87,1039,1363132800"; d="scan'208";a="233346935" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 10 Jul 2013 23:42:54 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6ANgr0q016324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 23:42:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 10 Jul 2013 18:42:53 -0500 From: "Cheng-Jia Lai (chelai)" To: Dave Taht , "Toerless Eckert (eckert)" Thread-Topic: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) Thread-Index: AQHOfaBDTO2Q2/ChiUO6fKWGKHceJZleig/Q Date: Wed, 10 Jul 2013 23:42:52 +0000 Message-ID: References: <20130710180147.GA614@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.161.170] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" , "tsvwg@ietf.org" , "aqm@ietf.org" Subject: Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 23:43:00 -0000 Yes, NM could also work with ECN (and it should be made so). In fact, we di= d implementation using WRED on routers that support ECN markings. If RTP en= dpoints support ECN markings, WRED will mark ECN instead of dropping the pa= ckets as avg Q size is between min & max threshold. But it still suffers fr= om unfairness at congestion, where the avg Q size starts to exceed the max = threshold for the lowest priority packet class... We did experience a hard time trying to properly configure WRED parameters = for preferential dropping of video packets with our NM implementation... It= is a good insight you said here: maybe it is worth exploring how our work = can perhaps use other AQM algorithms like CoDel, PIE, etc. In fact, NM doesn't need specific AQM to drop by probabilities... it will b= e interesting to see how it can work with delay-based dropping. However, NM= does require some "weighted" version of those AQMs. Hopefully a weighted v= ersion (if any) won't introduce new parameters (or too many) to configure t= he AQM. Regards, CJ -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of D= ave Taht Sent: Wednesday, July 10, 2013 12:02 PM To: Toerless Eckert (eckert) Cc: rmcat@ietf.org; rtcweb@ietf.org; tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality un= der congestion (draft-lai-tsvwg-normalizer-00.txt) On Wed, Jul 10, 2013 at 11:01 AM, Toerless Eckert (eckert) wrote: > When dealing with congestion for real-time datagram (UDP/RTP) based video= flows, one idea > that we think has shown to provide good value is to intelligently drop in= the network > preferentially the least important packets within a video flow, for examp= le non-referenced > P-frames, because their loss creates the lowest impact to video quality. I've begun to look at webrtc of late in the context of fq_codel. One thing that might work would be ECN marking important frames and not ECN marking others. Problem overall is that ecn can be gamed and is largely not enabled, and so on... > One of the main concerns raised against such schemes was one of fairness.= If flows > would start to indicate different priorities for packets in them, how wou= ld we > be able to avoid that flows would indicate all their packets to be of hig= h priority > to shift packet drops to other flows. Or even more importantly: how could= we motivate > flows to indicate that some of their packets are low priority without the= m having to > fear that they would experience more loss than than flows that don't do t= his. same gaming problem... > So, there is one draft that we would like to present (presumably in TSVWG= ) explaining > how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.tx= t > > (Actually, this is how we did solve the problem in our implementatin of i= ntelligent dropping, > so this is not theoretical). In the case of the fq_codel algorithm I can see a "delayed drop" mechanism happening, where upon deciding to drop, it could defer a drop up to a few packets based on the classification of the packet, say 3 packets at most. Since flows are already identified, this is kind of easy by adding another state variable... At the moment what I have deployed and tested most is a simple 3 tier fq_codel based shaper, which has a priority, best effort, and background queue. The priority queue is generally only DNS traffic, the background is only CS1, and fq_codel does such a good job with sparse streams in the general case that for VOIP, etc on the networks I fiddle with, there is no point in having much more than the BE queue. And presently all other markings are ignored. video is another story. (or could be, I don't know enough about webrtc's behaviors to "see" what will happen) So I can see trying to utilize the AF markings as you describe in your draft in codel's drop decision. While this is also subject to being gamed, the disincentives are slight. This is a little different from using "drop probability" as the decider, however, but I would hope that this mapping of the old AF style random drop ideas into the new style delay ideas could work... And what codel depends on is a definition of "TCP friendly". That if a stream is not going to behave in a tcp friendly manner, then an entirely different strategy for such flows seems necessary, and glomming on some additional state isn't going to be the right thing. > Now granted, the problem of fairness is but one element of building a com= plete ssytem > around the idea of intelligent dropping, so if folks here on the lists wo= uld like to > see for example > > a) how well can it work in routers to shift packet drops to low-prio pa= ckets I guess where I fall apart here is how to shift the encoders to send thinne= r streams at any level of packet drop. > b) whats the evidence that it's good for video quality > c) How should we do the marking best going forward > Then please let us know. We'd be very interested to provide insight into = the parts of > those pieces that we have also worked out or discuss the ones we have not= (primarily c ;-) I'd be interested in specific codecs, example video streams, and test scripts to try and fiddle with this, as well as viable metrics. > > Thanks! > Toerless > > In-Reply-To: > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: >> Hi all, >> >> We have submitted a new Internet draft to describe a Normalization Marke= r (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of = NM deployment is to create a new incentive for video encoders to generate m= ore discardable packets when using AF PHB in DIffServ. We are looking forwa= rd to your review comments. >> >> Best regards, >> CJ >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, February 08, 2013 6:25 PM >> To: Cheng-Jia Lai (chelai) >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert= ); Fred Yip (fyip) >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt >> >> >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >> has been successfully submitted by Cheng-Jia Lai and posted to the >> IETF repository. >> >> Filename: draft-lai-tsvwg-normalizer >> Revision: 00 >> Title: Normalization Marker for AF PHB Group in DiffServ >> Creation date: 2013-02-08 >> WG ID: Individual Submission >> Number of pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-nor= malizer-00.txt >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normali= zer >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-0= 0 >> >> >> Abstract: >> This memo describes a Normalization Marker (NM) at DiffServ (DS) >> nodes to normalize the distribution of DS codepoint (DSCP) markings >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is >> useful for traffic conditioning with Active Queue Management (AQM) >> when the AF PHB group is deployed for multimedia service classes that >> carry video packets with advanced codec technologies. Using NM can >> offer an incentive that is however missing in today's ecosystem of >> practical deployment, i.e., when congestion occurs in the AF PHB >> group, the network should allow a video codec to benefit from its >> effort of generating finer layers of intra-flow precedence (IFP) with >> discardable packets in a more balanced distribution. >> >> >> >> >> The IETF Secretariat >> > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From stefan.lk.hakansson@ericsson.com Wed Jul 10 23:43:58 2013 Return-Path: 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 B0A8521F9C88 for ; Wed, 10 Jul 2013 23:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=-1.180, BAYES_00=-2.599, 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 6URriWCx-DUS for ; Wed, 10 Jul 2013 23:43:53 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 095F221F9BF1 for ; Wed, 10 Jul 2013 23:43:52 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-6f-51de5426e834 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D8.E8.11907.6245ED15; Thu, 11 Jul 2013 08:43:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Thu, 11 Jul 2013 08:43:50 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "Hutton, Andrew" Thread-Topic: draft-ietf-rtcweb-use-cases-and-requirements - HTTP Only Firewall. Thread-Index: AQHOfXXNrAsp212+jEyOU4O3Fl3TyA== Date: Thu, 11 Jul 2013 06:43:49 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3104E7@ESESSMB209.ericsson.se> References: <20130627084022.19251.22430.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B1C306ECD@ESESSMB209.ericsson.se> <9F33F40F6F2CD847824537F3C4E37DDF1163B018@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvra5ayL1Agw/HdC3O9nWxW6z9187u wOSxZMlPJo8bt98zBzBFcdmkpOZklqUW6dslcGXcPbqTveCwScWCH0uZGxhvancxcnJICJhI /J9/mxHCFpO4cG89WxcjF4eQwFFGiZ5jW6GcRYwSR759ZAapYhMIlNi6bwEbiC0iYC3xYX4L WJxZwFBi8eztTCC2MFDNikUvmCFqgiTu3V7HBGHrSexf1wvWyyKgKvHj0CGwOK+Ar0Tj1+Us EMtOMUqsenEWrJkR6KTvp9YwQSwQl7j1ZD4TxKkCEkv2nGeGsEUlXj7+xwphK0k0LnnCClGv J3Fj6hQ2CFtbYtnC18wQywQlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYwcxanFSbnpRgab GIERcXDLb4sdjJf/2hxilOZgURLn3aJ3JlBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY6oK Q6DjucRHetOK2pasbCv7evzK0mJ/nfRzCVc+rpPWzjl+VrRqyc+P/KItua7sx78t1hG5KZv5 s+QdR6vDl1LrHlsOLreo7t+bHddKaqbO6BKUvXvmrmPz/P7uDY9SfnY4fuvTrxCe1fHWXzcr zu74SZmWnSXzgvf/7PdN/Wm4hDP6ksRiJZbijERDLeai4kQAuqfbNFYCAAA= Cc: "rt >> \"rtcweb@ietf.org\"" Subject: Re: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements - HTTP Only Firewall. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 06:43:58 -0000 Hi Andrew,=0A= =0A= thanks for catching this!=0A= =0A= F37 currently reads:=0A= =0A= "The browser must be able to send streams and data to a peer in the =0A= presence of FWs that only allows http(s) traffic."=0A= =0A= Would a change to:=0A= =0A= "The browser must be able to send streams and data to a peer in the =0A= presence of FWs that only allows traffic via a HTTP Proxy."=0A= =0A= be correct?=0A= =0A= Br,=0A= Stefan=0A= =0A= =0A= On 7/10/13 4:00 PM, Hutton, Andrew wrote:=0A= > Hi,=0A= >=0A= > Regarding the use case in 3.2.3 covering a HTTP only FW the text=0A= > states:=0A= >=0A= > "This use-case is almost identical to the Simple Video Communication=0A= > Service use-case (Section 3.2.1). The difference is that one of the=0A= > users is behind a FW that only allows http traffic".=0A= >=0A= > This needs to be changed to allow for the common case when a HTTP=0A= > Proxy is deployed so I suggest changing the last sentence to=0A= >=0A= > "The difference is that one of the users is behind a FW that only=0A= > allows traffic via a HTTP Proxy".=0A= >=0A= > There also needs to be a corresponding change to requirement F37.=0A= >=0A= > I believe we have previously discussed changing this but have to=0A= > admit I could not fine the e-mail chain so maybe it was during a=0A= > meeting.=0A= >=0A= > Regards Andy=0A= >=0A= >=0A= >=0A= >=0A= >> -----Original Message----- From: rtcweb-bounces@ietf.org=0A= >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan H=E5kansson LK=0A= >> Sent: 27 June 2013 09:50 To: rt >> "rtcweb@ietf.org" Subject:=0A= >> [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-=0A= >> use-cases-and-requirements-11.txt=0A= >>=0A= >> From the change log:=0A= >>=0A= >> o Described that the API requirements are really from a W3C=0A= >> perspective and are supplied as an appendix in the introduction.=0A= >> Moved API requirements to an Appendix.=0A= >>=0A= >> o Removed the "Conventions" section with the key-words and=0A= >> reference to RFC2119. Also changed uppercase MUST's/SHOULD's to=0A= >> lowercase.=0A= >>=0A= >> o Added a note on the proposed use of the document to the=0A= >> introduction.=0A= >>=0A= >> o Removed the note talking about WS from the "FW that only allows=0A= >> http" use-case.=0A= >>=0A= >> o Removed the word "Skype" that was used as example in one of the=0A= >> use-cases.=0A= >>=0A= >> o Clarified F3 (the req saying the everything the browser sends=0A= >> must be rate controlled).=0A= >>=0A= >> o Removed the TBD saying we need to define reasonable levels from=0A= >> the requirement saying that quality must be good even in presence=0A= >> of packet losses (F5), and changed "must" to "should" (Based on a=0A= >> list discussion involving Bernard).=0A= >>=0A= >> o Removed F6 ("The browser must be able to handle high loss and=0A= >> jitter levels in a graceful way."), also after a list discussion.=0A= >>=0A= >> o Clarified F7 (used to say that the browser must support fast=0A= >> stream switches, now says that reference frames must be inserted=0A= >> when requested). o Removed the questions from F9 (echo=0A= >> cancellation), F10 (syncronization), F21 (telephony codec).=0A= >>=0A= >> o Exchanged "restrictive firewalls" for "limited middleboxes" in=0A= >> F19 (as proposed by Martin).=0A= >>=0A= >> o Expanded DTMF and IVR in F22 (proposed by Martin)=0A= >>=0A= >> o Added ref to RFC5405 in F23 (proposed by Lars Eggert).=0A= >>=0A= >> o Exchanged "service provided" for "web application" in F32.=0A= >>=0A= >> o Changed the text in 3.2.1 that motivates F36 (new text "It is=0A= >> essential that media and data be encrypted, authenticated ... bound=0A= >> to the user identity."); and rewrote F36, included a ref to=0A= >> RFC5479.=0A= >>=0A= >> o Changed "quality of service" to "quality of experience" in F38.=0A= >>=0A= >> o Added F39.=0A= >>=0A= >> o Used new formulation of A17 (proposed by Martin).=0A= >>=0A= >> o Updated A20.=0A= >>=0A= >> o Updated A25.=0A= >>=0A= >> Things that have not been done:=0A= >>=0A= >> - No use-case on emergency services added (as said already in=0A= >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07253.html)=0A= >>=0A= >> - No use-case on real-time text added (as said already in=0A= >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07254.html)=0A= >>=0A= >> - No clarification on what solution(s) related to multiple=0A= >> resolutions of the same content added (discussed in=0A= >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07256.html=0A= >> but no input received).=0A= >>=0A= >> - The order of the requirements (Fn) is still a mess - but I kept=0A= >> it as is for this version to make diffing simpler. To be fixed in=0A= >> an upcoming version.=0A= >>=0A= >> Stefan=0A= >>=0A= >>=0A= >> -------- Original Message -------- Subject: New Version=0A= >> Notification for=0A= >> draft-ietf-rtcweb-use-cases-and-requirements-11.txt Date: 10:40=0A= >> From: internet-drafts@ietf.org To:=0A= >> Christer Holmberg , G=F6ran=0A= >> Eriksson AP , Stefan H=E5kansson=0A= >> LK , G=F6ran Eriksson AP=0A= >> =0A= >>=0A= >>=0A= >> A new version of I-D,=0A= >> draft-ietf-rtcweb-use-cases-and-requirements- 11.txt has been=0A= >> successfully submitted by Christer Holmberg and posted to the IETF=0A= >> repository.=0A= >>=0A= >> Filename: draft-ietf-rtcweb-use-cases-and-requirements Revision:=0A= >> 11 Title: Web Real-Time Communication Use-cases and Requirements=0A= >> Creation date: 2013-06-27 Group: rtcweb Number of pages: 30=0A= >> URL:=0A= >> http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-=0A= >>=0A= >>=0A= requirements-11.txt=0A= >> Status:=0A= >> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-=0A= >> requirements Htmlized:=0A= >> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-=0A= >> requirements-11 Diff:=0A= >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-use-cases-and-=0A= >> requirements-11=0A= >>=0A= >> Abstract: This document describes web based real-time communication=0A= >> use- cases. Requirements on the browser functionality are derived=0A= >> from use- cases.=0A= >>=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> The IETF Secretariat=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> _______________________________________________ rtcweb mailing=0A= >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From magnus.westerlund@ericsson.com Thu Jul 11 01:28:08 2013 Return-Path: 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 7C06D21F9D79 for ; Thu, 11 Jul 2013 01:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.64 X-Spam-Level: X-Spam-Status: No, score=-105.64 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 x2QCfzFQp6fh for ; Thu, 11 Jul 2013 01:28:02 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 500FB21F9D6A for ; Thu, 11 Jul 2013 01:27:59 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-69-51de6c8e1574 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 31.2B.05990.E8C6ED15; Thu, 11 Jul 2013 10:27:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.19) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.328.9; Thu, 11 Jul 2013 10:27:58 +0200 Message-ID: <51DE6CC9.2050505@ericsson.com> Date: Thu, 11 Jul 2013 10:28:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Cullen Jennings References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> In-Reply-To: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+JvrW5fzr1Ag39fVCw+rP/BaLH2Xzu7 A5PHkiU/mTwun//IGMAUxWWTkpqTWZZapG+XwJXxact/loLtfBXTrj1kbGB8zd3FyMkhIWAi MWvbCmYIW0ziwr31bF2MXBxCAocZJU5d62SCcJYxStyaewesildAW+LN3MNsIDaLgKrE4wsz GUFsNgELiZs/GsHiogLBEke2b2aBqBeUODnzCZgtIqAscW7HXbA5zALqEncWn2MHsYUFHCWa Ow6A9QoJWEocuzQVzOYUsJLYOHECC8R1khJbXrSzQ/TqSUy52sIIYctLNG+dzQzRqy3R0NTB OoFRaBaS1bOQtMxC0rKAkXkVI3tuYmZOernRJkZgsB7c8lt1B+OdcyKHGKU5WJTEeTfrnQkU EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJi6xWzf4VW/vzBJ8994ptcYdK0wqlKudaZQ8nSN lFohvhuWiSvS9s+T5QpQ+ZicVfbQzMYk7PssV77iniXRkpzGXHohrII36uS02/63W9kd2zCj mVnXtvwz28cFe2OXJiVfOuaj8TH4frVy9VO7byc/pK9yialZ8r58a8ahG9l8+4XazvDdV2Ip zkg01GIuKk4EAJfjcskkAgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:28:08 -0000 On 2013-07-05 02:47, Cullen Jennings wrote: > draft-ietf-rtcweb-rtp-usage 40 I disagree that that this is as low as 40%. There are some few thorny issues that might take some discussion to resolve. However, most things are from an authors perspective quite solid. I would say 60-70%. My main caveat is that I haven't seen that many reviews. You can expect an update prior to the deadline resolving some of the stated open issues and dealing with issues from Bernard's review. > draft-ietf-avtcore-6222bis 80 I expect this to be approved in a week or two, thus 90 > draft-ietf-avtcore-avp-codecs 80 Approved thus only publication left thus 95 > draft-ietf-avtext-multiple-clock-rates 70 This one is 90 as it is ready for publication request. It is awaiting the AVTEXT chair to act on it. > draft-lennox-rtcweb-rtp-media-type-mux 80 I wonder why this draft is listed here. Isn't the relevant content of this gone into the AVTCORE drafts: - draft-ietf-avtcore-multi-media-rtp-session - draft-ietf-avtcore-rtp-multi-stream ? > draft-ietf-avtcore-multi-media-rtp-session 70 > draft-lennox-avtcore-rtp-multi-stream 70 There is a WG version of this document draft-ietf-avtcore-rtp-multi-stream which in fact is being split into one recommendation and one optimization part. Updates to be submitted prior to deadline. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From andrew.hutton@siemens-enterprise.com Thu Jul 11 01:28:35 2013 Return-Path: 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 5A3AC21F9D5C for ; Thu, 11 Jul 2013 01:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, 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 0owZ3pH+V-uk for ; Thu, 11 Jul 2013 01:28:31 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABA221F924A for ; Thu, 11 Jul 2013 01:28:30 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 1E15B1EB8594; Thu, 11 Jul 2013 10:28:27 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Thu, 11 Jul 2013 10:28:26 +0200 From: "Hutton, Andrew" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= Thread-Topic: draft-ietf-rtcweb-use-cases-and-requirements - HTTP Only Firewall. Thread-Index: AQHOcxH6LsByzdb3v06Hk4dVDiPxEJlfOwVQ Date: Thu, 11 Jul 2013 08:28:26 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1163D42C@MCHP04MSX.global-ad.net> References: <20130627084022.19251.22430.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B1C306ECD@ESESSMB209.ericsson.se> <9F33F40F6F2CD847824537F3C4E37DDF1163B018@MCHP04MSX.global-ad.net> <1447FA0C20ED5147A1AA0EF02890A64B1C3104E7@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C3104E7@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rt >> \"rtcweb@ietf.org\"" Subject: Re: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements - HTTP Only Firewall. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:28:35 -0000 Sounds good to me. Regards Andy > -----Original Message----- > From: Stefan H=E5kansson LK [mailto:stefan.lk.hakansson@ericsson.com] > Sent: 11 July 2013 07:44 > To: Hutton, Andrew > Cc: rt >> "rtcweb@ietf.org" > Subject: Re: draft-ietf-rtcweb-use-cases-and-requirements - HTTP Only > Firewall. >=20 > Hi Andrew, >=20 > thanks for catching this! >=20 > F37 currently reads: >=20 > "The browser must be able to send streams and data to a peer in the > presence of FWs that only allows http(s) traffic." >=20 > Would a change to: >=20 > "The browser must be able to send streams and data to a peer in the > presence of FWs that only allows traffic via a HTTP Proxy." >=20 > be correct? >=20 > Br, > Stefan >=20 >=20 > On 7/10/13 4:00 PM, Hutton, Andrew wrote: > > Hi, > > > > Regarding the use case in 3.2.3 covering a HTTP only FW the text > > states: > > > > "This use-case is almost identical to the Simple Video Communication > > Service use-case (Section 3.2.1). The difference is that one of the > > users is behind a FW that only allows http traffic". > > > > This needs to be changed to allow for the common case when a HTTP > > Proxy is deployed so I suggest changing the last sentence to > > > > "The difference is that one of the users is behind a FW that only > > allows traffic via a HTTP Proxy". > > > > There also needs to be a corresponding change to requirement F37. > > > > I believe we have previously discussed changing this but have to > > admit I could not fine the e-mail chain so maybe it was during a > > meeting. > > > > Regards Andy > > > > > > > > > >> -----Original Message----- From: rtcweb-bounces@ietf.org > >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan H=E5kansson LK > >> Sent: 27 June 2013 09:50 To: rt >> "rtcweb@ietf.org" Subject: > >> [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb- > >> use-cases-and-requirements-11.txt > >> > >> From the change log: > >> > >> o Described that the API requirements are really from a W3C > >> perspective and are supplied as an appendix in the introduction. > >> Moved API requirements to an Appendix. > >> > >> o Removed the "Conventions" section with the key-words and > >> reference to RFC2119. Also changed uppercase MUST's/SHOULD's to > >> lowercase. > >> > >> o Added a note on the proposed use of the document to the > >> introduction. > >> > >> o Removed the note talking about WS from the "FW that only allows > >> http" use-case. > >> > >> o Removed the word "Skype" that was used as example in one of the > >> use-cases. > >> > >> o Clarified F3 (the req saying the everything the browser sends > >> must be rate controlled). > >> > >> o Removed the TBD saying we need to define reasonable levels from > >> the requirement saying that quality must be good even in presence > >> of packet losses (F5), and changed "must" to "should" (Based on a > >> list discussion involving Bernard). > >> > >> o Removed F6 ("The browser must be able to handle high loss and > >> jitter levels in a graceful way."), also after a list discussion. > >> > >> o Clarified F7 (used to say that the browser must support fast > >> stream switches, now says that reference frames must be inserted > >> when requested). o Removed the questions from F9 (echo > >> cancellation), F10 (syncronization), F21 (telephony codec). > >> > >> o Exchanged "restrictive firewalls" for "limited middleboxes" in > >> F19 (as proposed by Martin). > >> > >> o Expanded DTMF and IVR in F22 (proposed by Martin) > >> > >> o Added ref to RFC5405 in F23 (proposed by Lars Eggert). > >> > >> o Exchanged "service provided" for "web application" in F32. > >> > >> o Changed the text in 3.2.1 that motivates F36 (new text "It is > >> essential that media and data be encrypted, authenticated ... bound > >> to the user identity."); and rewrote F36, included a ref to > >> RFC5479. > >> > >> o Changed "quality of service" to "quality of experience" in F38. > >> > >> o Added F39. > >> > >> o Used new formulation of A17 (proposed by Martin). > >> > >> o Updated A20. > >> > >> o Updated A25. > >> > >> Things that have not been done: > >> > >> - No use-case on emergency services added (as said already in > >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07253.html) > >> > >> - No use-case on real-time text added (as said already in > >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07254.html) > >> > >> - No clarification on what solution(s) related to multiple > >> resolutions of the same content added (discussed in > >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg07256.html > >> but no input received). > >> > >> - The order of the requirements (Fn) is still a mess - but I kept > >> it as is for this version to make diffing simpler. To be fixed in > >> an upcoming version. > >> > >> Stefan > >> > >> > >> -------- Original Message -------- Subject: New Version > >> Notification for > >> draft-ietf-rtcweb-use-cases-and-requirements-11.txt Date: 10:40 > >> From: internet-drafts@ietf.org To: > >> Christer Holmberg , G=F6ran > >> Eriksson AP , Stefan H=E5kansson > >> LK , G=F6ran Eriksson AP > >> > >> > >> > >> A new version of I-D, > >> draft-ietf-rtcweb-use-cases-and-requirements- 11.txt has been > >> successfully submitted by Christer Holmberg and posted to the IETF > >> repository. > >> > >> Filename: draft-ietf-rtcweb-use-cases-and-requirements > Revision: > >> 11 Title: Web Real-Time Communication Use-cases and > Requirements > >> Creation date: 2013-06-27 Group: rtcweb Number of > pages: 30 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and- > >> > >> > requirements-11.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and- > >> requirements Htmlized: > >> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and- > >> requirements-11 Diff: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-use-cases-and- > >> requirements-11 > >> > >> Abstract: This document describes web based real-time communication > >> use- cases. Requirements on the browser functionality are derived > >> from use- cases. > >> > >> > >> > >> > >> > >> The IETF Secretariat > >> > >> > >> > >> > >> _______________________________________________ rtcweb mailing > >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > From andrew.hutton@siemens-enterprise.com Thu Jul 11 03:19:17 2013 Return-Path: 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 7076321F9FEA for ; Thu, 11 Jul 2013 03:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.095, 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 rkUZ9AUvoJ4Y for ; Thu, 11 Jul 2013 03:19:13 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0229B21F9FE9 for ; Thu, 11 Jul 2013 03:19:13 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 0D0F61EB85D5; Thu, 11 Jul 2013 12:19:10 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Thu, 11 Jul 2013 12:19:09 +0200 From: "Hutton, Andrew" To: Cullen Jennings , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Question about the status of various drafts Thread-Index: AQHOeRlA+vvnmXNqhUeR61l9KjX9j5lfTEdg Date: Thu, 11 Jul 2013 10:19:07 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1163E4A1@MCHP04MSX.global-ad.net> References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> In-Reply-To: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:19:17 -0000 There are things missing from the list. For example the charter and the requirements indicate that we need to addre= ss the firewall issue so we need a draft for that. I hope we will adopt draft-hutton-rtcweb-nat-firewall-considerations to cov= er this and of course assuming we do then I think it is nearly done but oth= ers might think differently.=20 I have not been through the requirements document to see if there are other= things missing. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: 05 July 2013 01:47 > To: rtcweb@ietf.org > Subject: [rtcweb] Question about the status of various drafts >=20 >=20 > As part of putting together some chair slides for Berlin, I'm trying to > get a very rough idea of where things are. I'd like to get folks input > on what percent done various drafts are where Done is a published RFC. >=20 > This is nearly impossible to do at any level of accuracy but I do want > to get a vague idea. I took a very rough stab below just to have a > starting point to get the conversation going. I'm sure my numbers are > mostly wrong but I have tried to ask a few people and sort of take the > central cluster of the guess. If you think I am way out, please provide > some feedback of what you think the number actually is. >=20 > I'm happy to get feedback on specific drafts or feedback of the form > they are all too low or too high. I do encourage people to > realistically look at the data tracker to see how long other drafts > have taken for each stage to get a baseline instead of just going with > their gut feel. >=20 > Thanks, Cullen >=20 > PS - if you are an author and look at the number next to your draft and > think it is way off, please please, say something. >=20 >=20 >=20 > draft-ietf-rtcweb-overview 80 > draft-ietf-rtcweb-use-cases-and-requirements 70 > http://dev.w3.org/2011/webrtc/editor/getusermedia.html 70 > draft-burnett-rtcweb-constraints-registry 80 > http://dev.w3.org/2011/webrtc/editor/webrtc.html 50 > draft-nandakumar-rtcweb-stun-uri 80 > draft-petithuguenin-behave-turn-uris 80 > draft-ietf-rtcweb-security 80 > draft-ietf-rtcweb-security-arch 80 > draft-muthu-behave-consent-freshness-02 50 > draft-ietf-rtcweb-data-channel 70 > draft-ietf-mmusic-sctp-sdp 70 > draft-jesup-rtcweb-data-protocol 50 > draft-ietf-tsvwg-sctp-dtls-encaps 70 > draft-ietf-rtcweb-rtp-usage 40 > draft-ietf-avtcore-6222bis 80 > draft-ietf-avtcore-avp-codecs 80 > draft-ietf-avtcore-srtp-encrypted-header-ext 80 > draft-ietf-avtext-multiple-clock-rates 70 > draft-lennox-rtcweb-rtp-media-type-mux 80 > draft-ietf-avtcore-rtp-circuit-breakers 70 > draft-ietf-avtcore-multi-media-rtp-session 70 > draft-lennox-avtcore-rtp-multi-stream 70 > draft-ietf-rtcweb-jsep 50 > draft-ietf-mmusic-msid 70 > draft-rescorla-mmusic-ice-trickle 25 > draft-ietf-mmusic-sdp-bundle-negotiation 50 > draft-nandakumar-mmusic-sdp-mux-attributes 25 > draft-dhesikan-tsvwg-rtcweb-qos 10 or 90 > draft-ietf-rtcweb-audio 50 > draft-ietf-payload-rtp-opus 90 > draft-ietf-payload-vp8-08 95 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Thu Jul 11 09:51:30 2013 Return-Path: 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 4BCE221F8E2A for ; Thu, 11 Jul 2013 09:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, 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 Oxi-B7WH228h for ; Thu, 11 Jul 2013 09:51:29 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id F10FD21F997B for ; Thu, 11 Jul 2013 09:51:07 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id u16so18010139iet.23 for ; Thu, 11 Jul 2013 09:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+6ts8r2f+5OyUnYVTpgfEFv5v4QC3Ap6KOEK7Hi36XE=; b=oXTRFQzUh0GphL6RDws0UpYdiPqHFaLJ2yVWid1ScWDmRjKgBvUBqUR/P6TxfHNvHJ yLdHOJbjbQpkSvCDjEgp2x93T2hF5nnqHTb8hfbc4Khrab3BCtoEMpVvxHykW9ksKAAR qdzACuZfkZ38p+sHMP/sn3pmCs0D3mhcCg76oDuRAZSyY3ql25cEhDku1VoH9/hd+Kmh jK52PkTHITyS3+A7qE8zdVrRUl+bGsK+6llE+n6wriXTgbqMyaOJhSqWT5u5iv9qX4uc XWkE4ud0dTwOMqwyE6YCjkAloK3XyaP7bM7qL9gDOTZme8x9N1SY63lEHn1GoGlV9wVs eKVA== MIME-Version: 1.0 X-Received: by 10.50.62.75 with SMTP id w11mr13880528igr.19.1373561466252; Thu, 11 Jul 2013 09:51:06 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Thu, 11 Jul 2013 09:51:06 -0700 (PDT) Date: Thu, 11 Jul 2013 09:51:06 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7bdc10e446205004e13f33ae Cc: Cullen Jennings Subject: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:51:30 -0000 --047d7bdc10e446205004e13f33ae Content-Type: text/plain; charset=ISO-8859-1 Greetings, Below is an initial draft agenda for the upcoming meeting. Since we have not yet reached the draft deadline (which is the 15th), there may be new drafts or updates that result in changes. We did already receive requests for NAT/Firewall traversal discussion, and the chairs will be working with the document authors to get them considered in the appropriate groups. As folks have probably noticed, we are meeting Thursday and Friday, after the MMUSIC sessions are complete (they are Tuesday and Wednesday). This should allow us to discuss the results on our first day. Please send feedback or change proposals to the list. thanks, Ted and Cullen Day 1: Should SDES be part of WebRTC security practice and, if so, how? Presentations: 30 minutes Discussion: 40 minutes Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents Presentation: 30 minutes Discussion: 30 minutes Security document updates Presentation: 10 minutes Discussion: 10 minutes Day 2: Chair Discussion: 10 minutes Use Case Requirements updates: Issues list presentation: 20 minutes Discussion: 20 minutes Data channel: Issues list presentation: 45 minutes Discussion: 45 minutes --047d7bdc10e446205004e13f33ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings,

Below is an initial draft agenda for the upcoming meeting= .=A0=A0 Since we have not yet reached the draft deadline (which is the 15th= ), there may be new drafts or updates that result in changes.=A0 We did alr= eady receive requests for NAT/Firewall traversal discussion, and the chairs= will be working with the document authors to get them considered in the ap= propriate groups.

As folks have probably noticed, we are meeting Thursday and Friday,=20 after the MMUSIC sessions are complete (they are Tuesday and Wednesday). Th= is should allow us to discuss the results on our first day.

Please = send feedback or change proposals to the list.

thanks,

Ted an= d Cullen

Day 1:

Should SDES be part of=A0 WebRTC security practice and, if so, how?
Pres= entations: 30 minutes
Discussion:=A0 40 minutes

Post-Plan A/Plan = B MMUSIC discussion of impact to RTCWEB documents
Presentation: 30 minut= es
Discussion: 30 minutes

Security document updates
Presentation: 10= minutes
Discussion: 10 minutes

Day 2:

Chair Discussion:= =A0 10 minutes

Use Case Requirements updates:
Issues list present= ation: 20 minutes
Discussion: 20 minutes

Data channel:
Issues list presentation:=A0 45 minutes
Discussion:= 45 minutes


--047d7bdc10e446205004e13f33ae-- From emcho@sip-communicator.org Thu Jul 11 10:35:55 2013 Return-Path: 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 D134621F9684 for ; Thu, 11 Jul 2013 10:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 U62aXZvuq8bx for ; Thu, 11 Jul 2013 10:35:43 -0700 (PDT) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id E7F4821F9F9C for ; Thu, 11 Jul 2013 10:35:35 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w15so788465vbf.7 for ; Thu, 11 Jul 2013 10:35:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/zTR42o6zeAkN4ZKfzkjrHqsY0Jr26BwLiAmffaWeKo=; b=RG5PS48V8L7zXVI2qx+x5Qz4UD0sHyPZCXGa3fr+yWdfs9NoZMccCS4rvppunRSnjJ VLGPqd9hOBPZWajc6IWzKqwfpxO/AVX9tlAoF5f5NFmNcTzxcdnyNE+zLCqRWFkyXLDW yu3H0Fk28LcUSl2FyunhTgUVrd4R/Pf80MFgw9k6EV8vpyJEaoCGGy/HR1TRJlwv1THH nrbRN8nM+INMWMuIs9lZknfbxeBH3kOlZ9CxVYTJmVsmBCl/oYAq58Fl7JCsOEQXa3T4 K39ic5miaUmEtLUIs02YRkMHVM/MK15TZZlo9gVDq8lbpggHOCAnADcpREz6+RoJAlaR S1DA== X-Received: by 10.52.16.105 with SMTP id f9mr18603895vdd.28.1373564135140; Thu, 11 Jul 2013 10:35:35 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [2607:f8b0:400c:c01::236]) by mx.google.com with ESMTPSA id aw3sm22505720vdc.2.2013.07.11.10.35.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 10:35:34 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so7519215veb.13 for ; Thu, 11 Jul 2013 10:35:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.165.239 with SMTP id zb15mr18758627vdb.44.1373564134344; Thu, 11 Jul 2013 10:35:34 -0700 (PDT) Received: by 10.221.45.71 with HTTP; Thu, 11 Jul 2013 10:35:34 -0700 (PDT) Received: by 10.221.45.71 with HTTP; Thu, 11 Jul 2013 10:35:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Jul 2013 19:35:34 +0200 Message-ID: From: Emil Ivov To: Ted Hardie Content-Type: multipart/alternative; boundary=001a11c24eb04e178204e13fd2cc X-Gm-Message-State: ALoCoQmcDIkN94u7OniikMvsZ56LOfd9h1qN7Om2jweUyiUTZ0oruDnsdo72dwhVAf5+K6dSkwMh Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:35:55 -0000 --001a11c24eb04e178204e13fd2cc Content-Type: text/plain; charset=ISO-8859-1 Hey Ted, I am sorry I must have missed your call for presentations. In you last mail on the subject you mentioned that we will be discussing No Plan in Berlin together with plans A and B. Could we please add this to the agenda? Emil --sent from my mobile On Jul 11, 2013 6:51 PM, "Ted Hardie" wrote: > Greetings, > > Below is an initial draft agenda for the upcoming meeting. Since we have > not yet reached the draft deadline (which is the 15th), there may be new > drafts or updates that result in changes. We did already receive requests > for NAT/Firewall traversal discussion, and the chairs will be working with > the document authors to get them considered in the appropriate groups. > > As folks have probably noticed, we are meeting Thursday and Friday, after > the MMUSIC sessions are complete (they are Tuesday and Wednesday). This > should allow us to discuss the results on our first day. > > Please send feedback or change proposals to the list. > > thanks, > > Ted and Cullen > > Day 1: > > Should SDES be part of WebRTC security practice and, if so, how? > Presentations: 30 minutes > Discussion: 40 minutes > > Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents > Presentation: 30 minutes > Discussion: 30 minutes > > Security document updates > Presentation: 10 minutes > Discussion: 10 minutes > > Day 2: > > Chair Discussion: 10 minutes > > Use Case Requirements updates: > Issues list presentation: 20 minutes > Discussion: 20 minutes > > Data channel: > Issues list presentation: 45 minutes > Discussion: 45 minutes > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c24eb04e178204e13fd2cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hey Ted,

I am sorry I must have missed your call for presentations.

In you last mail on the subject you mentioned that we will b= e discussing No Plan in Berlin together with plans A and B. Could we please= add this to the agenda?

Emil

--sent from my mobile

On Jul 11, 2013 6:51 PM, "Ted Hardie" = <ted.ietf@gmail.com> wrote:=
Greetings,

Below is an initial draft agenda for the upcoming meeting= .=A0=A0 Since we have not yet reached the draft deadline (which is the 15th= ), there may be new drafts or updates that result in changes.=A0 We did alr= eady receive requests for NAT/Firewall traversal discussion, and the chairs= will be working with the document authors to get them considered in the ap= propriate groups.

As folks have probably noticed, we are meeting Thursday and Friday,=20 after the MMUSIC sessions are complete (they are Tuesday and Wednesday). Th= is should allow us to discuss the results on our first day.

Please = send feedback or change proposals to the list.

thanks,

Ted an= d Cullen

Day 1:

Should SDES be part of=A0 WebRTC security practice and, if so, how?
Pres= entations: 30 minutes
Discussion:=A0 40 minutes

Post-Plan A/Plan = B MMUSIC discussion of impact to RTCWEB documents
Presentation: 30 minut= es
Discussion: 30 minutes

Security document updates
Presentation: 10= minutes
Discussion: 10 minutes

Day 2:

Chair Discussion:= =A0 10 minutes

Use Case Requirements updates:
Issues list present= ation: 20 minutes
Discussion: 20 minutes

Data channel:
Issues list presentation:=A0 45 minutes
Discussion:= 45 minutes



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

--001a11c24eb04e178204e13fd2cc-- From martin.thomson@gmail.com Thu Jul 11 11:08:13 2013 Return-Path: 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 B5A9821F9DCA for ; Thu, 11 Jul 2013 11:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, 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 rKEOL8tvf7BX for ; Thu, 11 Jul 2013 11:08:13 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 17B4121F99F2 for ; Thu, 11 Jul 2013 11:08:12 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so12962433wiv.8 for ; Thu, 11 Jul 2013 11:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y4Xl4PqfBprGBeTCyv3Mphwzs4I0+wbcqHC7RveutOk=; b=U/E3hfi9Fdyjb3g6xhx7WcRP3I4KDDRoSjTr+EDvZEWg/B0wY4Z99NZ+9/+MCjD0z2 pN/8gQwNdb4MWpMFuJIcD4OLufTYM5VanYAgh5X9TBvHHRjxwR6sFJ7JhLksTp8aZm2d qpwPdXhBP5aoKJmLM6Yt18QWVWCZAVkD5Js53Fz3hokCa6v4Eq0yEE8B7nthzousF6my MAgkMPmQY9RuCncv3oTQQsqZvulK2XdkgPudYxT92yEEz9YE0BWuy0VVyB9uujLOWTjJ BV9IAv7JQooKG//zEo4w3nQ+qtdLdtg3lDW1ofUTijhQyiVLdZDLBH1rfqF5BfFzhzMG fatA== MIME-Version: 1.0 X-Received: by 10.194.77.99 with SMTP id r3mr21912011wjw.5.1373566088838; Thu, 11 Jul 2013 11:08:08 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 11 Jul 2013 11:08:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Jul 2013 11:08:08 -0700 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 18:08:13 -0000 I can see some implied outcomes for some of the items. Would it help to list some (aspirational) goals. On 11 July 2013 09:51, Ted Hardie wrote: > Should SDES be part of WebRTC security practice and, if so, how? > Presentations: 30 minutes > Discussion: 40 minutes Are the chairs confident that this topic can be resolved in this time? We managed to fritter a similar amount of time away without conclusion in the past. I can see how you plan to accommodate overruns, but that just opens the possibility more time-wasting. How do we ensure that this discussion actually concludes? > Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents > Presentation: 30 minutes How are you planning to prepare for this? Do you have presenter candidates lined up? > Chair Discussion: 10 minutes I'm curious how you intend to spend this time. From fluffy@cisco.com Thu Jul 11 11:25:11 2013 Return-Path: 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 3CAB811E813D for ; Thu, 11 Jul 2013 11:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.543 X-Spam-Level: X-Spam-Status: No, score=-110.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 CntaNSwttt0i for ; Thu, 11 Jul 2013 11:25:06 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C52B211E8112 for ; Thu, 11 Jul 2013 11:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2064; q=dns/txt; s=iport; t=1373567094; x=1374776694; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DGkRO23gxmenCVk/qYI0z1uLMUXzTbznv+ablXZ6N0U=; b=Fo40aDMSgG1vaiWD/jZEQgnTbJikGVc6y7XrZpHMdkvloHXx2XPTczHt ZBY26W2KnHWFEZR+OXkHf5TLpaNPN5RmOCFDU3x7cKK/M/uJLfwB/wvfD RXwzcP3Zw+OHtcAvS9G77zWMGBdvQ3KHSsfq7u9gtaZGazJIYYaLP9+in E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAJid3lGtJXG+/2dsb2JhbABagwkyTcFQgQYWdIIjAQEBAwEBAQE3NAsFCwIBCBgKFBAhBgslAgQOBQiHdQMJBgyuVg2ITQSMeII2AjEHgwlsA5Vxjg2FJoMRgig X-IronPort-AV: E=Sophos;i="4.89,1045,1367971200"; d="scan'208";a="230723920" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 11 Jul 2013 18:24:51 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6BIOoIm024471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 18:24:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 13:24:50 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [rtcweb] Draft agenda for IETF 87 Thread-Index: AQHOflbcl1Vkg5a8kUyEc2Bfr2lLkplgGlUAgAAEqAA= Date: Thu, 11 Jul 2013 18:24:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <1A4E3254399B7742AFBD9101FA7A853B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 18:25:11 -0000 inline=20 On Jul 11, 2013, at 11:08 AM, Martin Thomson wro= te: > I can see some implied outcomes for some of the items. Would it help > to list some (aspirational) goals. >=20 > On 11 July 2013 09:51, Ted Hardie wrote: >> Should SDES be part of WebRTC security practice and, if so, how? >> Presentations: 30 minutes >> Discussion: 40 minutes >=20 > Are the chairs confident that this topic can be resolved in this time? > We managed to fritter a similar amount of time away without > conclusion in the past. I can see how you plan to accommodate > overruns, but that just opens the possibility more time-wasting. How > do we ensure that this discussion actually concludes? Thought on how to make that happen? Time needed ? >=20 >> Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents >> Presentation: 30 minutes >=20 > How are you planning to prepare for this? Do you have presenter > candidates lined up? This is a very draft agenda - part of the issues is we are not even at the = -00 draft deadline yet so I expect that by next week we should be able to f= igure out more details. We have scheduled the MMUSIC meetings before the RT= CWeb meetings in Berlin so at some level, some of this may change after the= MMUSIC meetings happen. Anyways, expect more details after we get to read = all the drafts and expect us to be a bit dynamic on this given what happens= in the MMUSIC meeting.=20 >=20 >> Chair Discussion: 10 minutes >=20 > I'm curious how you intend to spend this time. We would like to inform folks of a few things happening in other WG (TURN, = NAT, BEHAVE etc) but we would also like to have a discussion about what it = takes to get to "Done" for the first iteration of all this stuff. We need t= o get WG feedback on what work is left and what needs to be prioritized.=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu Jul 11 12:03:25 2013 Return-Path: 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 4A42A21F9A37 for ; Thu, 11 Jul 2013 12:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, 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 Jz3hpjWZllzB for ; Thu, 11 Jul 2013 12:03:24 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 73D1521F88DB for ; Thu, 11 Jul 2013 12:03:24 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so7468670wgh.12 for ; Thu, 11 Jul 2013 12:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cqxQXJPb1D4824CTqGUgRMk7OyNgZYnZQYp47BOupNI=; b=Ws8MbGTH3//0Nh/Re5C6g8a1FuJAT+hqEPufsMJPzVYa1i4G969/Ok9ZC7RRSq53OE F8FYjYyHEsq8N69RgDo+dmF699gEVKsTxYYiiLnlOfw052mih4ttnNcjdmhg0b/LGyZ/ IhdvnhQPF4Wr+7i7OCvAYqRiy15XJJZJbrqPKdEpsU9Ddq//yJsMEFAljlIKrBx6BgXr MUd2FNfN09WBqGOrU4Io9K6c8a0+0AOpLRUyD+MK5v+uIYTsv9kQzeL2+VNFiq02jfgL rhoEk0V/yuSzXkb0s9wN6u9DjavTFzqKFC4LAjPH2cTHa8meD9FxUQXeNa869sLk96mA jhNg== MIME-Version: 1.0 X-Received: by 10.194.77.99 with SMTP id r3mr22032589wjw.5.1373569403553; Thu, 11 Jul 2013 12:03:23 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 11 Jul 2013 12:03:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Jul 2013 12:03:23 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:03:25 -0000 On 11 July 2013 11:24, Cullen Jennings (fluffy) wrote: > On Jul 11, 2013, at 11:08 AM, Martin Thomson w= rote: >> On 11 July 2013 09:51, Ted Hardie wrote: >>> Should SDES be part of WebRTC security practice and, if so, how? >>> Presentations: 30 minutes >>> Discussion: 40 minutes >> >> Are the chairs confident that this topic can be resolved in this time? >> We managed to fritter a similar amount of time away without >> conclusion in the past. I can see how you plan to accommodate >> overruns, but that just opens the possibility more time-wasting. How >> do we ensure that this discussion actually concludes? > > Thought on how to make that happen? Time needed ? There are two aspects of this that I, personally, want to see resolved before I'm happy that we can conclude on this: - a story for the gateway-to-other-stuff scenarios (where other-stuff is mostly just all-the-existing-stuff) - a story for conference scenarios The first two could conclude that we need to re-encrypt at these points, but that would require some justification. Or we could conclude that we need SDES, or maybe that DTLS-SRTP+EKT is the right answer. I'm stretching my recall capacity, but I recall promises from several people to present on various aspects. If those presentations cover the ground well enough, then we can go into a discussion well-prepared. Time needed will then depend on the time that each presenter needs. If we can get to the point where the space is well-enough understood, we should be able to conclude. That does require a modest amount of time for each participant to make an impassioned plea at the mic. And pontification takes time. We may need to consider the alternative decision making process here. >>> Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents >>> Presentation: 30 minutes >> >> How are you planning to prepare for this? Do you have presenter >> candidates lined up? > > This is a very draft agenda - part of the issues is we are not even at th= e -00 draft deadline yet so I expect that by next week we should be able to= figure out more details. We have scheduled the MMUSIC meetings before the = RTCWeb meetings in Berlin so at some level, some of this may change after t= he MMUSIC meetings happen. Anyways, expect more details after we get to rea= d all the drafts and expect us to be a bit dynamic on this given what happe= ns in the MMUSIC meeting. You'd best have some candidates lined up to produce some discussion material in short order. >>> Chair Discussion: 10 minutes >> >> I'm curious how you intend to spend this time. > > We would like to inform folks of a few things happening in other WG (TURN= , NAT, BEHAVE etc) but we would also like to have a discussion about what i= t takes to get to "Done" for the first iteration of all this stuff. We need= to get WG feedback on what work is left and what needs to be prioritized. Thanks. That helps. That might be too short a time for that list. From fluffy@cisco.com Thu Jul 11 12:04:59 2013 Return-Path: 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 176E921F9307 for ; Thu, 11 Jul 2013 12:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Ns6OxgflX294 for ; Thu, 11 Jul 2013 12:04:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 87BCC21F93B9 for ; Thu, 11 Jul 2013 12:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=498; q=dns/txt; s=iport; t=1373569493; x=1374779093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Qr6rh+Z9OVZHtx20RcmzuRjUvxryQPNWUBpPtg+/kcI=; b=DYqxjeKh9FU9XrpUuxz+dYleNYzhtgjQpdmpI/6uXFtSD5+q+bUUhd9z 8FwzknahRd+JGgzypSDI30QuETTGgcQv2E7URzor8c1pgOhY8EHUhHyVW l2HYpHqhKUCOlgHVACmG8E6n7FQjE8feTOcliF+bMhDuTUhEFXeL4lzYQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoFAHMB31GtJXHA/2dsb2JhbABagwl/gj+/FIEHFnSCIwEBAQMBHVwFCwIBCA4UJDIlAgQOBQiIAQa3Uo4vfwIxB4MJbAOIb6A1gxGBcTc X-IronPort-AV: E=Sophos;i="4.89,1045,1367971200"; d="scan'208";a="233547225" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jul 2013 19:04:53 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6BJ4rqE022464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 19:04:53 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 14:04:52 -0500 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [rtcweb] Draft agenda for IETF 87 Thread-Index: AQHOflbcl1Vkg5a8kUyEc2Bfr2lLkplgETwAgAAY8wA= Date: Thu, 11 Jul 2013 19:04:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.7] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:04:59 -0000 On Jul 11, 2013, at 10:35 AM, Emil Ivov wrote: > Hey Ted, >=20 > I am sorry I must have missed your call for presentations. >=20 > In you last mail on the subject you mentioned that we will be discussing = No Plan in Berlin together with plans A and B. Could we please add this to = the agenda? >=20 > Emil >=20 >=20 No. We believe that conversation needs to happen in the W3C WebRTC WG. I ex= pect to see a message from W3C chairs on this at some point.=20 From martin.thomson@gmail.com Thu Jul 11 12:37:53 2013 Return-Path: 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 1EF7B11E8112 for ; Thu, 11 Jul 2013 12:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, 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 ziZy9Di5QBzW for ; Thu, 11 Jul 2013 12:37:52 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6D811E8114 for ; Thu, 11 Jul 2013 12:37:49 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so7971567wid.16 for ; Thu, 11 Jul 2013 12:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=epZCuvn3gKKee6/YemIR37zJcbCZqzK0Tyt2458Hkgw=; b=jEVRzDjpuyHlmavhfmNs+v6llNVZUvndmWGhQAiIGeR973dSn5FB/RMITHSZBf4bVK CytaBpgGrgdYnOZHvS4+y9mVRmbVP0HA5Qby2AW41jR0+8a+rVA9ZwqvG3akJQ187DoP NUm2/xZIre9vlghUWtwGslEZV7orF3HK0/i0FG23XG929PjBvDeewyMCfCqV30oRh5N+ mwYXSjEAAGkS928PVywIVfek9ennEqE2soraekKkEXD6ZE5t/URToK93ksp6JWLEWqHq CNDzn0m0UsWGSZ1p/HzyQy6h/k17lm2Qct3byw1S+XHH+ypyBeiffJWIF8UObhsLj9ti 0jPg== MIME-Version: 1.0 X-Received: by 10.181.12.10 with SMTP id em10mr20921598wid.14.1373571469247; Thu, 11 Jul 2013 12:37:49 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 11 Jul 2013 12:37:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Jul 2013 12:37:49 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:37:53 -0000 On 11 July 2013 12:04, Cullen Jennings (fluffy) wrote: > On Jul 11, 2013, at 10:35 AM, Emil Ivov >> In you last mail on the subject you mentioned that we will be discussing No Plan in Berlin together with plans A and B. Could we please add this to the agenda? > > No. We believe that conversation needs to happen in the W3C WebRTC WG. I expect to see a message from W3C chairs on this at some point. I'm a little nervous about this. Where does the decision on the separation of responsibilities (API vs. SDP) get made? From adam@nostrum.com Thu Jul 11 12:46:59 2013 Return-Path: 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 2508E21F9A31 for ; Thu, 11 Jul 2013 12:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 4F9yOafBLQvP for ; Thu, 11 Jul 2013 12:46:58 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 86C3C21F9A10 for ; Thu, 11 Jul 2013 12:46:58 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6BJkpmM078737 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 11 Jul 2013 14:46:52 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51DF0BA6.8040609@nostrum.com> Date: Thu, 11 Jul 2013 14:46:46 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Martin Thomson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:46:59 -0000 On 7/11/13 14:37, Martin Thomson wrote: > On 11 July 2013 12:04, Cullen Jennings (fluffy) wrote: >> On Jul 11, 2013, at 10:35 AM, Emil Ivov >>> In you last mail on the subject you mentioned that we will be discussing No Plan in Berlin together with plans A and B. Could we please add this to the agenda? >> No. We believe that conversation needs to happen in the W3C WebRTC WG. I expect to see a message from W3C chairs on this at some point. > I'm a little nervous about this. Where does the decision on the > separation of responsibilities (API vs. SDP) get made? Jointly by the chairs of RTCWEB and WebRTC, based on and , one would presume. /a From martin.thomson@gmail.com Thu Jul 11 13:18:17 2013 Return-Path: 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 930AC21E8054 for ; Thu, 11 Jul 2013 13:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, 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 yfC-PR6WGbL8 for ; Thu, 11 Jul 2013 13:18:17 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DE75421E8063 for ; Thu, 11 Jul 2013 13:18:16 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so7331014wgh.26 for ; Thu, 11 Jul 2013 13:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nHkXiCXiwL9Pg2xQuUaui2rlkaoMdIJTzihUYJLYUoM=; b=S7RTlQrBoF8+Z2HS8lhMzsSuP4qsSyOwihpcrAJjHhqLJ0ircIAgk/yjH8imdyCLTV vflmokiWb/sBt9E/uaBoQwIRLJ2Lv/kBuJsGI/AqwwCJ88+u/Gyh+4l5k1OjCzlZaklH Om0r7wD/Oc9t45FWzyxrrDTMgsSjenkoTll9V+qnWHfwAny2W9DYZSpQ5o10XuWcXCRY RJBepiIiHLlaP3k5qqN8h9vJoLzYHA3PuNa/goHHCqmTvES+OVrUXPTJigrTf+0mQrZv 6IqOR6w5O7wCXj00oLm8Y7lRJCstoiHZIoSUsNuTmGOAUX1wXCEi5oacXBBp2IVDpKQF rBhA== MIME-Version: 1.0 X-Received: by 10.180.39.236 with SMTP id s12mr38674241wik.14.1373573895710; Thu, 11 Jul 2013 13:18:15 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 11 Jul 2013 13:18:15 -0700 (PDT) In-Reply-To: <51DF0BA6.8040609@nostrum.com> References: <51DF0BA6.8040609@nostrum.com> Date: Thu, 11 Jul 2013 13:18:15 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:18:17 -0000 On 11 July 2013 12:46, Adam Roach wrote: > Jointly by the chairs of RTCWEB and WebRTC, based on > and > , one would presume. To be perfectly clear, that's precisely what makes me nervous. From csp@csperkins.org Thu Jul 11 14:24:34 2013 Return-Path: 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 3097C21F9FC6 for ; Thu, 11 Jul 2013 14:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 KRacR+ozhfoD for ; Thu, 11 Jul 2013 14:24:29 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id CC67E11E817F for ; Thu, 11 Jul 2013 14:24:28 -0700 (PDT) Received: from [81.187.2.149] (port=49146 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UxOLe-0000S0-8U; Thu, 11 Jul 2013 22:24:22 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <066.cafc635ba698c26a8adc82620078c6ab@trac.tools.ietf.org> Date: Thu, 11 Jul 2013 22:24:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <046FCAA3-277C-4020-8AAF-26D420AF33D5@csperkins.org> References: <066.cafc635ba698c26a8adc82620078c6ab@trac.tools.ietf.org> To: Bernard Aboba X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: rtcweb@ietf.org Subject: Re: [rtcweb] #19: Section 7.2: Congestion Control Extensions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 21:24:34 -0000 On 20 Apr 2013, at 02:48, rtcweb issue tracker wrote: > #19: Section 7.2: Congestion Control Extensions >=20 > 7.2. RTCP Extensions for Congestion Control >=20 > As described in Section 5.1.6, the Temporary Maximum Media Stream = Bit > Rate (TMMBR) request is supported by WebRTC senders. This request > can be used by a media receiver to impose limitations on the media > sender based on the receiver's determined bit-rate limitations, to > provide a limited means of congestion control. >=20 > (tbd: What other RTP/RTCP extensions are needed?) >=20 > With proprietary congestion control algorithms issues can arise = when > different algorithms and implementations interact in a = communication > session. If the different implementations have made different > choices in regards to the type of adaptation, for example one = sender > based, and one receiver based, then one could end up in situation > where one direction is dual controlled, when the other direction is > not controlled. >=20 > (tbd: How to ensure that both paths and sender and receiver based > solutions can interact) >=20 > [BA] Some nasty unresolved issues here. In particular, I am concerned > about potential gaps in worldview between sender-side and = receiver-side > congestion control implementations. Is our goal here to guarantee = that a sender-side implementation can interoperate with a receiver-side > implementation? Or that a sender-side implementation has the = information it needs? I don't think either is the goal. As we don't have a congestion control = solution from RMCAT yet, I believe the goal for this draft should be to = allow signalling of known boundary conditions on the acceptable rate, = and to ensure the necessary RTP/RTCP features to implement congestion = control are available in implementations. TMMBR requests fall into the former category. They're not designed, or = suitable, for effective congestion control. Rather, they allow = signalling of known constraints within which congestion control can = operate. Section 7.1 of the draft, immediately before the text you = quoted, says this better. I will therefore remove the paragraph about = TMMBR you quoted from the draft. The draft says "(tbd: What other RTP/RTCP extensions are needed?)". I = think this answer here is none: we have RTP/AVPF feedback, RTP header = extensions, non-compound packets, and the ability to tune the reporting = interval. These are enough to convey congestion reports in a reasonably = low-overhead manner. Anything else will depend on the algorithm, and so = belongs in the draft defining the standard RMCAT congestion control = algorithm. The text quoted about proprietary congestion control algorithms, and = interoperability between sender- and receiver-driven algorithms is a = real issue, but not one that I think this draft can resolve. I'll move = the quoted text into Section 7.4, where it fits better, and try to = clarify that the problem is one that should be addressed by agreement on = the congestion control algorithm at the signalling layer, and an = effective standard from RMCAT. --=20 Colin Perkins http://csperkins.org/ From chelai@cisco.com Thu Jul 11 15:12:53 2013 Return-Path: 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 A64A711E81B8; Thu, 11 Jul 2013 15:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OkV7TGImtcal; Thu, 11 Jul 2013 15:12:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 878A121F9F71; Thu, 11 Jul 2013 15:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7145; q=dns/txt; s=iport; t=1373580768; x=1374790368; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NUnOPGj7zzwp20P6uiTxzgY1YkvIZDpAnv+QSQYKbiQ=; b=eEwnJIK47h+N2O6rxImHnqu8lXo6APSzs0CINzpwp3jItXvh3omTgvwv cBhkJAk/ho1nyOVMTzPcptmSA/qv0smcJo3IZOfxtruR9sDMKzpCQuj7H lvGm1w7Ch+rmjbemK6wT+Uvdqegz+Asewa4f5oJYVvhYBUvfzym0n2Ynm k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJYs31GtJV2a/2dsb2JhbABagwY0T8FWgQcWdIIjAQEBAwE6KwIEDgUHBAIBCBEBAwEBAQoUBQQHMhQDBggCBAENBQgBiAAGDLdpjimBBwYrBwaDA2wDmQaQJIFYgTmBaEA X-IronPort-AV: E=Sophos;i="4.89,647,1367971200"; d="scan'208";a="233612568" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jul 2013 22:12:47 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6BMClOL011042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 22:12:47 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 17:12:47 -0500 From: "Cheng-Jia Lai (chelai)" To: ken carlberg , "Toerless Eckert (eckert)" Thread-Topic: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) Thread-Index: AQHOflB/BP/LxZhvSUuqg6JURoTBKJlgAPVA Date: Thu, 11 Jul 2013 22:12:46 +0000 Message-ID: References: <20130710180147.GA614@cisco.com> <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> In-Reply-To: <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.161.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rmcat@ietf.org" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 22:12:53 -0000 Ken, Thanks very much for the comment and showing an interest in our draft. Yes, I agree it is beneficial if the intra-flow priorities info can be carr= ied in some bit field other than DSCP markings. I guess we need to better c= larify that NM is not necessarily specific to AF PHB but potentially applic= able to other service classes. (In fact, our implementation did try DPI in = RTP and H.264 NAL unit header for that, with some limited overheads in pack= et processing.) We know there can be a lot of intelligent ways to carrying priorities in pa= ckets (e.g. your TLV in RTP hdr) which are likely beyond our knowledge and = expertise, so we just introduced the CB mode in Section 3.1, quoted as foll= ows: "When NM operates in "color-blind" (CB) mode, which is optionally supported, it reads certain bits field(s) other than the AF-markings in the packets to determine the actual drop precedence of that packet. This implies that NM may need DPI in the packets, e.g. parsing into H.264 AVC header in each RTP packets, or alternatively use some method where the drop precedence is carried from the encoder in a customized bits field other than the AF-marking in each packet." CB might not be the best name... sorry if confusing. Anyway, we hope this a= llows NM to collaborate better with video endpoints. Regards, CJ -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of k= en carlberg Sent: Thursday, July 11, 2013 9:05 AM To: Toerless Eckert (eckert) Cc: rmcat@ietf.org; rtcweb@ietf.org; tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality un= der congestion (draft-lai-tsvwg-normalizer-00.txt) Toerless, some food for thought... about 10 years ago, I put together a draft that added an optional TLV prior= itization header to RTP to accomplish something similar in terms of having = the app decide which was the better RTP packet to drop during times of cong= estion. My aim was to have these decisions made at forwarding application-= layer gateways that did not act as a RTP/RTCP endpoint. The strength of th= e approach (in my opinion :-) was that it could span pockets of non-diff-se= rv regions and still carry significance downstream. The weakness was the n= eed for DPI if one wanted to make a more informed decision along the path a= bout dropping a packet. I wonder if such a dual-layer design might be helpful in your efforts. In = any case, I have an interest in the normalizer draft. -ken On Jul 10, 2013, at 2:01 PM, Toerless Eckert (eckert) wr= ote: > When dealing with congestion for real-time datagram (UDP/RTP) based video= flows, one idea > that we think has shown to provide good value is to intelligently drop in= the network > preferentially the least important packets within a video flow, for examp= le non-referenced > P-frames, because their loss creates the lowest impact to video quality. >=20 > One of the main concerns raised against such schemes was one of fairness.= If flows=20 > would start to indicate different priorities for packets in them, how wou= ld we > be able to avoid that flows would indicate all their packets to be of hig= h priority > to shift packet drops to other flows. Or even more importantly: how could= we motivate > flows to indicate that some of their packets are low priority without the= m having to > fear that they would experience more loss than than flows that don't do t= his. >=20 > So, there is one draft that we would like to present (presumably in TSVWG= ) explaining > how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.tx= t >=20 > (Actually, this is how we did solve the problem in our implementatin of i= ntelligent dropping, > so this is not theoretical). >=20 > Now granted, the problem of fairness is but one element of building a com= plete ssytem > around the idea of intelligent dropping, so if folks here on the lists wo= uld like to > see for example=20 >=20 > a) how well can it work in routers to shift packet drops to low-prio pac= kets > b) whats the evidence that it's good for video quality > c) How should we do the marking best going forward >=20 > Then please let us know. We'd be very interested to provide insight into = the parts of > those pieces that we have also worked out or discuss the ones we have not= (primarily c ;-) >=20 > Thanks! > Toerless >=20 > In-Reply-To: >=20 > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: >> Hi all, >>=20 >> We have submitted a new Internet draft to describe a Normalization Marke= r (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of = NM deployment is to create a new incentive for video encoders to generate m= ore discardable packets when using AF PHB in DIffServ. We are looking forwa= rd to your review comments. >>=20 >> Best regards, >> CJ >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: Friday, February 08, 2013 6:25 PM >> To: Cheng-Jia Lai (chelai) >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert= ); Fred Yip (fyip) >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt >>=20 >>=20 >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >> has been successfully submitted by Cheng-Jia Lai and posted to the >> IETF repository. >>=20 >> Filename: draft-lai-tsvwg-normalizer >> Revision: 00 >> Title: Normalization Marker for AF PHB Group in DiffServ >> Creation date: 2013-02-08 >> WG ID: Individual Submission >> Number of pages: 15 >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-nor= malizer-00.txt >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normali= zer >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-0= 0 >>=20 >>=20 >> Abstract: >> This memo describes a Normalization Marker (NM) at DiffServ (DS) >> nodes to normalize the distribution of DS codepoint (DSCP) markings >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is >> useful for traffic conditioning with Active Queue Management (AQM) >> when the AF PHB group is deployed for multimedia service classes that >> carry video packets with advanced codec technologies. Using NM can >> offer an incentive that is however missing in today's ecosystem of >> practical deployment, i.e., when congestion occurs in the AF PHB >> group, the network should allow a video codec to benefit from its >> effort of generating finer layers of intra-flow precedence (IFP) with >> discardable packets in a more balanced distribution. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 From mary.ietf.barnes@gmail.com Thu Jul 11 17:06:33 2013 Return-Path: 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 223A821E804D for ; Thu, 11 Jul 2013 17:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 J7sFarZnEaNy for ; Thu, 11 Jul 2013 17:06:32 -0700 (PDT) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 85EC221F9D17 for ; Thu, 11 Jul 2013 17:06:32 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so4824673qeb.29 for ; Thu, 11 Jul 2013 17:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ru/EErxH0GFA3u3MMNnGo6o06LtquyQ8mKenjS5Wedg=; b=PzkrVT5Ljbc8WW/sAfUs5NHifK+OLlj1nQx6MS/lHeIoTKtGzjZURFIVqWGgzql9Ci svJQPAjYivMEmbJTfjYxy7nyiq5XH0qQYS/Tn1s9O7VdBW7v5rj9PUkgKoQqny80N3To 2OF3R318dqfSiVeSyUezKmTNZ47DMzLI+nvxvEqUvRsUAHZY4KsvPojrSPziK7ttYCij 8+p5yvN3/r8X07gTXKgb7WW5PSV+Kd9aVIi0Bv9sxM5DGp0wkOIzMCvCKTSx9BmqtpRo Hx1Xp4ZYqeSw3ZCuF2yoKpeepN0PJjn1+wOZ1dNSyT3kvRWpgmQzcnUtyc3MmI4GoAW+ wJog== MIME-Version: 1.0 X-Received: by 10.49.104.72 with SMTP id gc8mr32963124qeb.35.1373587589463; Thu, 11 Jul 2013 17:06:29 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Thu, 11 Jul 2013 17:06:29 -0700 (PDT) In-Reply-To: References: <51DF0BA6.8040609@nostrum.com> Date: Thu, 11 Jul 2013 19:06:29 -0500 Message-ID: From: Mary Barnes To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 00:06:33 -0000 On Thu, Jul 11, 2013 at 3:18 PM, Martin Thomson wrote: > On 11 July 2013 12:46, Adam Roach wrote: >> Jointly by the chairs of RTCWEB and WebRTC, based on >> and >> , one would presume. > > To be perfectly clear, that's precisely what makes me nervous. [MB] Me too. [/MB] > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From eckert@cisco.com Thu Jul 11 17:30:11 2013 Return-Path: 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 B977011E81CD; Thu, 11 Jul 2013 17:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 NuO9b9KJv9uj; Thu, 11 Jul 2013 17:30:07 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF6D11E814B; Thu, 11 Jul 2013 17:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6647; q=dns/txt; s=iport; t=1373589007; x=1374798607; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=sdMEUzGCmqchvnyBL+sbXziVn3KVC7c8kICxgmS5pBo=; b=ZKy66lRG1QCElEDaZyZ+Z1H24LlmRQRqLta9tM2Fr1JdrW+4AdJ44Fbx tJPZf0lf+AK3xh4hjCAwoqRdPofJ+OuPU9Gn3syXdnFCZpq30PCFlmppx 7s5moaYo7yYtS39AOsRIo0MYwCx30Jt+eMi5Ol249P2L1ewtKjscDHP5n s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAKBN31GrRDoI/2dsb2JhbABagwY0wiWBBxZ0giMBAQEEOisUDAQLEQEDAQEBCRoEBw8FMgMGDhMJiAUNtnSPYQcGgwNsA4knjjQBgSqQJIFYgVkc X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="82739177" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 12 Jul 2013 00:30:03 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6C0U2Bb010157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 00:30:02 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r6C0U2ac003309; Thu, 11 Jul 2013 17:30:02 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r6C0U232003308; Thu, 11 Jul 2013 17:30:02 -0700 Date: Thu, 11 Jul 2013 17:30:02 -0700 From: Toerless Eckert To: ken carlberg Message-ID: <20130712003002.GA30036@cisco.com> References: <20130710180147.GA614@cisco.com> <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> User-Agent: Mutt/1.4.2.2i Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 00:30:11 -0000 Thanks, Ken Indeed yes, that's exactly the line of thought that we would like to see proceed as well. Any URL still existing for that draft ? "application layer gateway" could specifically mean switching MCU using intelligent dropping in conjunction with outbound congestion control. I definitely would like to see RTP headers as the ultimatele marking option even for routers to do intelligent dropping (or other packet processing "beyond DSCP)). Intra-flow (per-packet) DSCP is just a big pain (aka: impossible) for applications. Many OSs don't have any APIs to support this. And DSCP management in networks is already difficult enough as it stands. Would certainly like to see if there is interest to write up r present more pieces of this puzzle, especially an RTP extension. We just felt that the fairness in intelligent dropping was the biggest concern our video application folks had, that's why we wanted to explain how that piece could work first. Cheers Toerless On Thu, Jul 11, 2013 at 12:04:58PM -0400, ken carlberg wrote: > Toerless, > > some food for thought... > > about 10 years ago, I put together a draft that added an optional TLV prioritization header to RTP to accomplish something similar in terms of having the app decide which was the better RTP packet to drop during times of congestion. My aim was to have these decisions made at forwarding application-layer gateways that did not act as a RTP/RTCP endpoint. The strength of the approach (in my opinion :-) was that it could span pockets of non-diff-serv regions and still carry significance downstream. The weakness was the need for DPI if one wanted to make a more informed decision along the path about dropping a packet. > > I wonder if such a dual-layer design might be helpful in your efforts. In any case, I have an interest in the normalizer draft. > > -ken > > > On Jul 10, 2013, at 2:01 PM, Toerless Eckert (eckert) wrote: > > > When dealing with congestion for real-time datagram (UDP/RTP) based video flows, one idea > > that we think has shown to provide good value is to intelligently drop in the network > > preferentially the least important packets within a video flow, for example non-referenced > > P-frames, because their loss creates the lowest impact to video quality. > > > > One of the main concerns raised against such schemes was one of fairness. If flows > > would start to indicate different priorities for packets in them, how would we > > be able to avoid that flows would indicate all their packets to be of high priority > > to shift packet drops to other flows. Or even more importantly: how could we motivate > > flows to indicate that some of their packets are low priority without them having to > > fear that they would experience more loss than than flows that don't do this. > > > > So, there is one draft that we would like to present (presumably in TSVWG) explaining > > how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.txt > > > > (Actually, this is how we did solve the problem in our implementatin of intelligent dropping, > > so this is not theoretical). > > > > Now granted, the problem of fairness is but one element of building a complete ssytem > > around the idea of intelligent dropping, so if folks here on the lists would like to > > see for example > > > > a) how well can it work in routers to shift packet drops to low-prio packets > > b) whats the evidence that it's good for video quality > > c) How should we do the marking best going forward > > > > Then please let us know. We'd be very interested to provide insight into the parts of > > those pieces that we have also worked out or discuss the ones we have not (primarily c ;-) > > > > Thanks! > > Toerless > > > > In-Reply-To: > > > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: > >> Hi all, > >> > >> We have submitted a new Internet draft to describe a Normalization Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of NM deployment is to create a new incentive for video encoders to generate more discardable packets when using AF PHB in DIffServ. We are looking forward to your review comments. > >> > >> Best regards, > >> CJ > >> > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, February 08, 2013 6:25 PM > >> To: Cheng-Jia Lai (chelai) > >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); Fred Yip (fyip) > >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt > >> > >> > >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt > >> has been successfully submitted by Cheng-Jia Lai and posted to the > >> IETF repository. > >> > >> Filename: draft-lai-tsvwg-normalizer > >> Revision: 00 > >> Title: Normalization Marker for AF PHB Group in DiffServ > >> Creation date: 2013-02-08 > >> WG ID: Individual Submission > >> Number of pages: 15 > >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer > >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 > >> > >> > >> Abstract: > >> This memo describes a Normalization Marker (NM) at DiffServ (DS) > >> nodes to normalize the distribution of DS codepoint (DSCP) markings > >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is > >> useful for traffic conditioning with Active Queue Management (AQM) > >> when the AF PHB group is deployed for multimedia service classes that > >> carry video packets with advanced codec technologies. Using NM can > >> offer an incentive that is however missing in today's ecosystem of > >> practical deployment, i.e., when congestion occurs in the AF PHB > >> group, the network should allow a video codec to benefit from its > >> effort of generating finer layers of intra-flow precedence (IFP) with > >> discardable packets in a more balanced distribution. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > Cisco NSSTG Systems & Technology Architecture > > SDN: Let me play with the network, mommy! > > > -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From fluffy@cisco.com Thu Jul 11 17:55:50 2013 Return-Path: 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 8996C21F9A05 for ; Thu, 11 Jul 2013 17:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 yA1LdZBAYotE for ; Thu, 11 Jul 2013 17:55:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AA36E11E824A for ; Thu, 11 Jul 2013 17:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1246; q=dns/txt; s=iport; t=1373590545; x=1374800145; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zo26QuWc/X3ASpKaHS/K1qTnqZZ20/r8m6ueFVp53rE=; b=XIl3PVtRd2KF0GuZGH0ZQvreyhbchUb54MO77ZEcqkMlHsKBbCtq8jkF 98q+wbjRSrXvA8Oi4a2+92F4Re08t40vqN3tUmM1N4hViMkuGWkxOScCp CujvBGIHWMh3HtwAdeF3Z1LjLJk1Y40PDIphkBqh/GRVeSvi8ff8iKy+5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHRT31GtJXG8/2dsb2JhbABagwY0T8FWgQcWdIIjAQEBAwF5BQsCAQgYCiQhESUCBA4FCId1AwkGDK4YDYhejHiCNgIxAgWDCWwDiG+NBIMTin6FJoMRgig X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="233865259" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 12 Jul 2013 00:55:45 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6C0tj45029250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 00:55:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 19:55:44 -0500 From: "Cullen Jennings (fluffy)" To: Mary Barnes Thread-Topic: [rtcweb] Draft agenda for IETF 87 Thread-Index: AQHOfm4gl1Vkg5a8kUyEc2Bfr2lLkplgNbUAgAAIzICAAD/FgIAADcIA Date: Fri, 12 Jul 2013 00:55:44 +0000 Message-ID: References: <51DF0BA6.8040609@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.7] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 00:55:50 -0000 On Jul 11, 2013, at 5:06 PM, Mary Barnes wrote: > On Thu, Jul 11, 2013 at 3:18 PM, Martin Thomson > wrote: >> On 11 July 2013 12:46, Adam Roach wrote: >>> Jointly by the chairs of RTCWEB and WebRTC, based on >>> and >>> , one would presume. >>=20 >> To be perfectly clear, that's precisely what makes me nervous. >=20 > [MB] Me too. [/MB] One might read this to imply that this was chair decision about the scope, = but in this case, I don't think the chairs have very much to do with if the= no-plan draft happens to be in scope of this WG or not. As the authors ex= plained it, it is purely an API change with no changes to anything on the w= ire. Everyone in this WG seems to agree on where API works happens and I ha= ve not heard any disagreement on that. Of course that not surprising that t= here is not disagreement on this as the charters of WebRTC and RTCWeb seem = relatively clear on this. On the decision of what to put on a draft agenda before the -00 deadline, o= f course Ted and I take responsibility for the current draft agenda. From eckert@cisco.com Thu Jul 11 17:59:38 2013 Return-Path: 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 8882811E824B; Thu, 11 Jul 2013 17:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YgvWWiyiQHbf; Thu, 11 Jul 2013 17:59:34 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 796A911E80D7; Thu, 11 Jul 2013 17:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7279; q=dns/txt; s=iport; t=1373590774; x=1374800374; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=rng01PAmE220ZiRAmBpWAp4N6BZfP+Fg3gTDUeiHZEk=; b=Ix7ERua4f4o01bi2JsVpKC9pmcrvsKleBfWUp3ltxyT2uWxZKqYRvAYw Xjn9zwgXYwTvOXw+URzy1ODCnIN0rcubDhFLBksJyzGuQ3x6UJb71DIOO jwrUB07evh4oX0nNjrOU6S4e9KHinIY7cFrFumw/58bWNCX51HVsNTBO6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgJAPZT31GrRDoJ/2dsb2JhbABagwY0wiAEAYEHFnSCIwEBAQMBMgEyFAUHBAsRAQMBAQEJAxcEBw8FMgMGDg8ECYgABQ23A45KgRcHBoMDbAOJJ440AYEqkCSBWIFZHA X-IronPort-AV: E=Sophos;i="4.89,649,1367971200"; d="scan'208";a="85758034" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 12 Jul 2013 00:59:31 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6C0xUBk001901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jul 2013 00:59:30 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r6C0xUTF004788; Thu, 11 Jul 2013 17:59:30 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r6C0xU6u004787; Thu, 11 Jul 2013 17:59:30 -0700 Date: Thu, 11 Jul 2013 17:59:30 -0700 From: "Toerless Eckert (eckert)" To: Dave Taht Message-ID: <20130712005930.GB30036@cisco.com> References: <20130710180147.GA614@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 00:59:38 -0000 On Wed, Jul 10, 2013 at 12:02:26PM -0700, Dave Taht wrote: > I've begun to look at webrtc of late in the context of fq_codel. > > One thing that might work would be ECN marking important frames and > not ECN marking others. True. But i think there are at least 3 layers of priority that would really be great to have: really important packet (long term reference frames), "normal" packets, and low-proirity-packets (eg: discardable P). And ECN could only do two. Most of the time when you would want intelligent dropping, your drop rate should be fairly low, eg< 20% instantaneous within the queue. If you can do discardable P-frames it's of course best to drop those first. Only when you instantaneously have really big bursts would you want to drop "normal" packets and refrain to protection really important packets. This does work really well with different queue-length (or WRED profiles). If you only had two priorities (via ECN) it's hard to say how you would best assign these two priorities to at least those three priority levels. > Problem overall is that ecn can be gamed and is largely not > enabled, and so on... Well. The gaming could be inhibited exactly by this draft because it would try to guarantee the same amount of drops on a per-flow or "class" basis, so if you're trying to game the system, you would be put into your own class and would still see the same amount of drops as other flows. Well, the main issue is really to redesignate ECN for a different semantic than what it has today. And indicating packet priority is just not quite the same as congestion feedback. > In the case of the fq_codel algorithm I can see a "delayed drop" > mechanism happening, > where upon deciding to drop, it could defer a drop up to a few packets > based on the classification > of the packet, say 3 packets at most. Since flows are already > identified, this is kind of easy > by adding another state variable... Yes, this is all quite interesting. We also played around with droppping during enqueuing vs. during dequeuing, so there are a bunch of things that could optimize intelligent dropping if you can build a more intelligent queue. [...] > > So I can see trying to utilize the AF markings as you describe in your > draft in codel's > drop decision. While this is also subject to being gamed, the > disincentives are slight. Lets separate the marking from the mechanism to inhibit gaming. This draft really is about the latter, and the marking described with AF is really just an example. Yes, it would be lovely to agree on markings too. > And what codel depends on is a definition of "TCP friendly". That if a > stream is not going to behave in a tcp friendly manner, then an entirely > different strategy for such flows seems necessary, and glomming on some > additional state isn't going to be the right thing. Who stood up at RMCAT some time back and claimed to have worked for > 10 years on TCP and declared TCP not self friendly to itself, so RMCAT shouldn't bother ? ;-)) Kidding aside: Intelligent dropping IMHO makes perfect sense when being applied to RT traffic sharing a queue friendly with TCP. And intelligent dropping can then still improve the performance. I am pretty positive though that RMCAT traffic in general will behave better and get lower delay and more video-appropriate loss if it can have its own queue. Primarily because it will just take decates to root out all the bad TCP traffic. I don't think that the strategies if you do or if you don't share the queue with TCP would be fundamentally be different. > a) how well can it work in routers to shift packet drops to low-prio packets > > I guess where I fall apart here is how to shift the encoders to send thinner > streams at any level of packet drop. Video codec coders are known to be able to do crazy cool things. There are a bunch of known mechanisms and probably more proprietary ones. > I'd be interested in specific codecs, example video streams, and test > scripts to try and fiddle with this, as well as viable metrics. Sure. Best done in person. If we're going to be at the WG for this, we can talk on the side how we've been doing this. Cheers Toerless > > Thanks! > > Toerless > > > > In-Reply-To: > > > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: > >> Hi all, > >> > >> We have submitted a new Internet draft to describe a Normalization Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of NM deployment is to create a new incentive for video encoders to generate more discardable packets when using AF PHB in DIffServ. We are looking forward to your review comments. > >> > >> Best regards, > >> CJ > >> > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, February 08, 2013 6:25 PM > >> To: Cheng-Jia Lai (chelai) > >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); Fred Yip (fyip) > >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt > >> > >> > >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt > >> has been successfully submitted by Cheng-Jia Lai and posted to the > >> IETF repository. > >> > >> Filename: draft-lai-tsvwg-normalizer > >> Revision: 00 > >> Title: Normalization Marker for AF PHB Group in DiffServ > >> Creation date: 2013-02-08 > >> WG ID: Individual Submission > >> Number of pages: 15 > >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer > >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 > >> > >> > >> Abstract: > >> This memo describes a Normalization Marker (NM) at DiffServ (DS) > >> nodes to normalize the distribution of DS codepoint (DSCP) markings > >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is > >> useful for traffic conditioning with Active Queue Management (AQM) > >> when the AF PHB group is deployed for multimedia service classes that > >> carry video packets with advanced codec technologies. Using NM can > >> offer an incentive that is however missing in today's ecosystem of > >> practical deployment, i.e., when congestion occurs in the AF PHB > >> group, the network should allow a video codec to benefit from its > >> effort of generating finer layers of intra-flow precedence (IFP) with > >> discardable packets in a more balanced distribution. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > Cisco NSSTG Systems & Technology Architecture > > SDN: Let me play with the network, mommy! > > > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From fluffy@iii.ca Thu Jul 11 18:09:42 2013 Return-Path: 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 DBE8B11E827F for ; Thu, 11 Jul 2013 18:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.815, 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 yk4+2KvzqC5o for ; Thu, 11 Jul 2013 18:09:37 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 689F811E8279 for ; Thu, 11 Jul 2013 18:09:34 -0700 (PDT) Received: from sjc-vpn6-1543.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B581622E256; Thu, 11 Jul 2013 21:09:27 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: <51DE6CC9.2050505@ericsson.com> Date: Thu, 11 Jul 2013 18:09:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> <51DE6CC9.2050505@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 01:09:43 -0000 On Jul 11, 2013, at 1:28 AM, Magnus Westerlund = wrote: > On 2013-07-05 02:47, Cullen Jennings wrote: >> draft-ietf-rtcweb-rtp-usage 40 >=20 > I disagree that that this is as low as 40%. There are some few thorny > issues that might take some discussion to resolve. However, most = things > are from an authors perspective quite solid. I would say 60-70%. Not sure how I got 40 on that one. 60-70 makes sense. (and rest of = email but just wanted to reply to this part right away= From stefan.lk.hakansson@ericsson.com Fri Jul 12 00:35:12 2013 Return-Path: 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 5350C21F9E3F for ; Fri, 12 Jul 2013 00:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.234 X-Spam-Level: X-Spam-Status: No, score=-5.234 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 SZQimfZpYhZ9 for ; Fri, 12 Jul 2013 00:35:03 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8146F21F9E3C for ; Fri, 12 Jul 2013 00:35:02 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-9e-51dfb1a4bb6c Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 11.B0.19388.4A1BFD15; Fri, 12 Jul 2013 09:35:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 09:35:00 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Martin Thomson Thread-Topic: [rtcweb] Draft agenda for IETF 87 Thread-Index: AQHOflbnoSh5pMdyC0qq6yOZjrenEA== Date: Fri, 12 Jul 2013 07:35:00 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C311367@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre7SjfcDDdYvYrHomMxmce3MP0aL tf/a2R2YPab83sjqsXPWXXaPJUt+MgUwR3HZpKTmZJalFunbJXBlvHl3kb1gE1/F43+zWRoY 73F3MXJySAiYSHycNJkFwhaTuHBvPVsXIxeHkMBhRolbb1awQziLGCXurO5iA6liEwiU2Lpv AZgtIqArsejsA3YQm1kgSmLHph6mLkYODmEBPYk5DZEgpoiAvsTnzcYQ1XoS/Qc2MYPYLAKq Ej9n3AObwivgK9H0fxsTxKqFTBJ/3vUzgiQYgQ76fmoNE8R4cYlbT+YzQRwqILFkz3lmCFtU 4uXjf6wQtpLEjw2XWCDq9SRuTJ3CBmFrSyxb+JoZYpmgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsoqRPTcxMye93HwTIzA6Dm75bbCDcdN9sUOM0hwsSuK8m/XOBAoJpCeWpGanphakFsUX leakFh9iZOLglGpglFLhD3R5xOUk5Do1capvmvjmjpKIp3NqurXdFF2fSB4WdxPvXsVruMuj 7P5st1Wvhd59atA1SWGdcTb5ro3ghZaPYWqNL4s3aat1Jv3knvd95peA7D0Hp3Ob+qftDp5+ rWb3uTMMvxu71h65yfAt3Vews5fRYvHE/Zu2forZ5JsTxPJacN15JZbijERDLeai4kQASc8E j1wCAAA= Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 07:35:12 -0000 On 7/11/13 9:38 PM, Martin Thomson wrote:=0A= > On 11 July 2013 12:04, Cullen Jennings (fluffy) =0A= > wrote:=0A= >> On Jul 11, 2013, at 10:35 AM, Emil Ivov =0A= >>> In you last mail on the subject you mentioned that we will be=0A= >>> discussing No Plan in Berlin together with plans A and B. Could=0A= >>> we please add this to the agenda?=0A= >>=0A= >> No. We believe that conversation needs to happen in the W3C WebRTC=0A= >> WG. I expect to see a message from W3C chairs on this at some=0A= >> point.=0A= >=0A= > I'm a little nervous about this. Where does the decision on the=0A= > separation of responsibilities (API vs. SDP) get made?=0A= =0A= (I have not been able to confer with any of the other chairs, so this is = =0A= just my personal opinion):=0A= =0A= To me it seems pretty straightforward to a certain point:=0A= =0A= * The SDP (if we opt to continue using SDP for this purpose) that goes=0A= on the signaling wire between the browsers is defined by IETF (and by=0A= the rtcweb WG I presume even though MMUSIC seems to have some stake)=0A= =0A= * JS APIs to:=0A= ** Apply an SDP (e.g. received on the signaling channel) to the browser=0A= ** Hand an SDP generated by the browser over to the application (for=0A= transmission over the signaling wire presumably)=0A= ** Influencing/modifying the contents of the SDP=0A= * All belongs to the W3C WebRTC=0A= =0A= What seems unclear to me is where we define what modifications to the=0A= SDP that are allowed - and when. Even though the ambition is to have=0A= APIs that makes SDP mangling an exception, we will still see that=0A= happening.=0A= =0A= > _______________________________________________ rtcweb mailing list=0A= > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From andrew.hutton@siemens-enterprise.com Fri Jul 12 02:01:25 2013 Return-Path: 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 D6A6921F9E4E for ; Fri, 12 Jul 2013 02:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=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 64rhNvzMp2tQ for ; Fri, 12 Jul 2013 02:01:16 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD0221F98AD for ; Fri, 12 Jul 2013 02:01:09 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 3BB3723F05D8; Fri, 12 Jul 2013 11:01:06 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Fri, 12 Jul 2013 11:01:05 +0200 From: "Hutton, Andrew" To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Draft agenda for IETF 87 - FW Issues Thread-Index: AQHOflbuioJxfw6BTUiF3V93e/1K7plguuEQ Date: Fri, 12 Jul 2013 09:01:05 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF116406C8@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF116406C8MCHP04MSXglobal_" MIME-Version: 1.0 Cc: Cullen Jennings Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:01:25 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF116406C8MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the FW traversal discussion then I still think we need a discussi= on in the RTCWEB WG and I hope to persuade the chairs that this is the case= . We have requirements in the use case draft and charter items that need solu= tions and this is a real issue impacting RTCWeb trials today. Regards Andy From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ted Hardie Sent: 11 July 2013 17:51 To: rtcweb@ietf.org Cc: Cullen Jennings Subject: [rtcweb] Draft agenda for IETF 87 Greetings, Below is an initial draft agenda for the upcoming meeting. Since we have = not yet reached the draft deadline (which is the 15th), there may be new dr= afts or updates that result in changes. We did already receive requests fo= r NAT/Firewall traversal discussion, and the chairs will be working with th= e document authors to get them considered in the appropriate groups. As folks have probably noticed, we are meeting Thursday and Friday, after t= he MMUSIC sessions are complete (they are Tuesday and Wednesday). This shou= ld allow us to discuss the results on our first day. Please send feedback or change proposals to the list. thanks, Ted and Cullen Day 1: Should SDES be part of WebRTC security practice and, if so, how? Presentations: 30 minutes Discussion: 40 minutes Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents Presentation: 30 minutes Discussion: 30 minutes Security document updates Presentation: 10 minutes Discussion: 10 minutes Day 2: Chair Discussion: 10 minutes Use Case Requirements updates: Issues list presentation: 20 minutes Discussion: 20 minutes Data channel: Issues list presentation: 45 minutes Discussion: 45 minutes --_000_9F33F40F6F2CD847824537F3C4E37DDF116406C8MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding the FW traversa= l discussion then I still think we need a discussion in the RTCWEB WG and I= hope to persuade the chairs that this is the case.

 <= /p>

We have requirements in t= he use case draft and charter items that need solutions and this is a real = issue impacting RTCWeb trials today.  

 <= /p>

Regards=

Andy

 <= /p>

 <= /p>

 <= /p>

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: 11 July 2013 17:51
To: rtcweb@ietf.org
Cc: Cullen Jennings
Subject: [rtcweb] Draft agenda for IETF 87

 

Greetings,

Below is an initial draft agenda for the upcoming meeting.   Sinc= e we have not yet reached the draft deadline (which is the 15th), there may= be new drafts or updates that result in changes.  We did already rece= ive requests for NAT/Firewall traversal discussion, and the chairs will be working with the document authors to get them consi= dered in the appropriate groups.

As folks have probably noticed, we are meeting Thursday and Friday, after t= he MMUSIC sessions are complete (they are Tuesday and Wednesday). This shou= ld allow us to discuss the results on our first day.

Please send feedback or change proposals to the list.

thanks,

Ted and Cullen

Day 1:

Should SDES be part of  WebRTC security practice and, if so, how?
Presentations: 30 minutes
Discussion:  40 minutes

Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents
Presentation: 30 minutes
Discussion: 30 minutes

Security document updates
Presentation: 10 minutes
Discussion: 10 minutes

Day 2:

Chair Discussion:  10 minutes

Use Case Requirements updates:
Issues list presentation: 20 minutes
Discussion: 20 minutes

Data channel:
Issues list presentation:  45 minutes
Discussion: 45 minutes

--_000_9F33F40F6F2CD847824537F3C4E37DDF116406C8MCHP04MSXglobal_-- From ibc@aliax.net Fri Jul 12 02:11:35 2013 Return-Path: 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 4F66421F9A2A for ; Fri, 12 Jul 2013 02:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 XF+pGxoLy0Pa for ; Fri, 12 Jul 2013 02:11:30 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id A30B821F9C17 for ; Fri, 12 Jul 2013 02:11:23 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s1so4886252qcw.15 for ; Fri, 12 Jul 2013 02:11:23 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=1WMiL/m7KFC+Yj/NfQktvI25hnKjQcBCo5+/e1QrIpM=; b=SpPP+dKjgxxz0J+ZausXWrSefckcqMYtVKd+IsyqtiDkNqhl3vfO4gLQ07ElS/C83R J7ptgmrYAKpir1l9IffLzhmYmCnlWc9WS4QEa+UBh1yRTtQBlVZj1d7RMzAsZamJ7FJx Lh/NDw34Xj/6GJ0g4HxORMvFdC69WIsa2J0mQB9GCTohXf418k2av/dYdPRMs7R6cB5s d5gcXWzs5dI0dz6juxLMxNKjch7NUS9o5SgJcho4Ew6hX8eIK2509y7dLjXbYGD62Dyz f+mvP5OTCRWu4LRoHe9DikZj+MTS+PPidRHvR8MsuXzJCXAJBU6G3VtrLG2DKylGkZbw WT/A== X-Received: by 10.49.98.138 with SMTP id ei10mr34092896qeb.3.1373620283061; Fri, 12 Jul 2013 02:11:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Fri, 12 Jul 2013 02:11:02 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C311367@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C311367@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 12 Jul 2013 11:11:02 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnLwKfhKlSroDevoNiHf89u1e1PyKe9X/j7rkkCeQAAmYMHKJ5/KyI4QVmEP6xBgrqjxysR Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:11:35 -0000 2013/7/12 Stefan H=C3=A5kansson LK : > * JS APIs to: > ** Apply an SDP (e.g. received on the signaling channel) to the browser > ** Hand an SDP generated by the browser over to the application (for > transmission over the signaling wire presumably) > ** Influencing/modifying the contents of the SDP > * All belongs to the W3C WebRTC I've never seen an API in which the application requests some data to the core, and then mangles such a data before sending it to the peer. This is like if I ask the browser to send video, the browser gives me a media description (I will not assume SDP) with ptime=3D20, and I mangle the media description to set ptime=3D50, while at the same time I have no idea whether my browser can send RTP with ptime=3D50 or not. It's just awesome. -- I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Fri Jul 12 03:34:21 2013 Return-Path: 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 4753D21F9DAF for ; Fri, 12 Jul 2013 03:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, 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 9iMFWYSNbeps for ; Fri, 12 Jul 2013 03:34:15 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9091C21F9DA0 for ; Fri, 12 Jul 2013 03:34:14 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-d8-51dfdba170f1 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 95.24.11907.1ABDFD15; Fri, 12 Jul 2013 12:34:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 12:34:09 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Draft agenda for IETF 87 Thread-Index: AQHOflbnoSh5pMdyC0qq6yOZjrenEA== Date: Fri, 12 Jul 2013 10:34:08 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C311A4C@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C311367@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvre7C2/cDDfZ2aVt0TGazmL7PxuLa mX+MFmv/tbM7sHica3jP7jHl90ZWj52z7rJ7LFnykymAJYrLJiU1J7MstUjfLoEr4+Yuk4Iv XBXPWo6yNzDe5+hi5OSQEDCR+HB+JjuELSZx4d56ti5GLg4hgaOMEpeef2cCSQgJLGKU2PPG FMRmEwiU2LpvARuILSJgKXFj7k1mEJtZoJVRYtEVxS5GDg5hAT2JOQ2RIKaIgL7E583GENV6 Ev0HNoFVswioSlxddIARxOYV8JXoWtHMArFpDbNE02RBEJsR6Jzvp9YwQUwXl7j1ZD4TxJkC Ekv2nGeGsEUlXj7+xwphK0n82HCJBaJeT+LG1ClsELa2xLKFr5khdglKnJz5hGUCo+gsJGNn IWmZhaRlFpKWBYwsqxg5ilOLk3LTjQw2MQJj5eCW3xY7GC//tTnEKM3BoiTOu0XvTKCQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGRiFHPiv5fXuatlyNPppmftAs2X+7zR11HcMlU906mFec YIrMmKXxxetrn6jPS7lp0w4vnRO4ae4O0a6tmhbR81utLx9i3/DuupIl5x4vA5b5mT1vHBh6 Xl5hbHh/fFacwTwtw9J9z7wy6m5f3coeEPTwsUZzZ5/OCc2IwwnBHDvO9j86uVl+lxJLcUai oRZzUXEiAHdwZdFjAgAA Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 10:34:21 -0000 On 7/12/13 11:11 AM, I=F1aki Baz Castillo wrote:=0A= > 2013/7/12 Stefan H=E5kansson LK :=0A= >> * JS APIs to:=0A= >> ** Apply an SDP (e.g. received on the signaling channel) to the browser= =0A= >> ** Hand an SDP generated by the browser over to the application (for=0A= >> transmission over the signaling wire presumably)=0A= >> ** Influencing/modifying the contents of the SDP=0A= >> * All belongs to the W3C WebRTC=0A= >=0A= > I've never seen an API in which the application requests some data to=0A= > the core, and then mangles such a data before sending it to the peer.=0A= > This is like if I ask the browser to send video, the browser gives me=0A= > a media description (I will not assume SDP) with ptime=3D20, and I=0A= > mangle the media description to set ptime=3D50, while at the same time I= =0A= > have no idea whether my browser can send RTP with ptime=3D50 or not.=0A= =0A= I think this is not at all the way it should be done; if people think =0A= there is a need to define a specific ptime there should be an API that =0A= allows for that (and that has means of letting the app know what the =0A= allowed ranges are, or at least what is actually used). Let's go and do =0A= that in the WebRTC WG.=0A= =0A= > It's just awesome.=0A= >=0A= >=0A= > --=0A= > I=F1aki Baz Castillo=0A= > =0A= >=0A= =0A= From ibc@aliax.net Fri Jul 12 03:41:42 2013 Return-Path: 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 751B221F9D2A for ; Fri, 12 Jul 2013 03:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 leNhvnFaNvxe for ; Fri, 12 Jul 2013 03:41:37 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4E55D21F9D01 for ; Fri, 12 Jul 2013 03:41:37 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so4950962qeb.41 for ; Fri, 12 Jul 2013 03:41:36 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=iwMuB4/Hp5DoCU+XWnf8M0cS5yZKX9Jd+PQcVETH1S8=; b=RfaKDjvBCMwkj5cgxI4DyHvfR4Rw1qSwHo1x19CRBf1IwvwWnTmArtY5PpGXAF+a5V wRGjQ+cFr5+lx/c0JbmBDpiRKdFLJXHgACfeqC51nyM/U+GO/eeh3VQD8kDWN8COPYRn Vj819HmDrC13F4GGBFdIf+RLSYs0lbb72pto6ZwLdgmnWl5q347Tx4f6D1vri+0l7dqE sDSg7xr6Nq1/5TFON0fqtEw6BWhKg0Lwk7VTLUdZhbbLYcOiHGscCuncZpIwBFqM5GS5 nHwBTuOELotaBMYAjH60CaB9SaVdbmeLk8TK8bKvFbdmkebnMtUb9AjQjmcLDCbhKEcW 2IlA== X-Received: by 10.49.98.138 with SMTP id ei10mr34390499qeb.3.1373625696799; Fri, 12 Jul 2013 03:41:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Fri, 12 Jul 2013 03:41:15 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C311A4C@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C311367@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C311A4C@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 12 Jul 2013 12:41:15 +0200 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkXi0L7uR6Sfrkd0A/RhMxGTOSL0kWVauacHgqz1Ju2W6DnTOAHkTkIjA03bTNdIH0LbJJf Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 10:41:42 -0000 2013/7/12 Stefan H=C3=A5kansson LK : >> I've never seen an API in which the application requests some data to >> the core, and then mangles such a data before sending it to the peer. >> This is like if I ask the browser to send video, the browser gives me >> a media description (I will not assume SDP) with ptime=3D20, and I >> mangle the media description to set ptime=3D50, while at the same time I >> have no idea whether my browser can send RTP with ptime=3D50 or not. > > I think this is not at all the way it should be done; if people think > there is a need to define a specific ptime there should be an API that > allows for that (and that has means of letting the app know what the > allowed ranges are, or at least what is actually used). That looks a real JS Object based API, right? ;) > Let's go and do > that in the WebRTC WG. Sure. -- I=C3=B1aki Baz Castillo From pthatcher@google.com Fri Jul 12 07:37:11 2013 Return-Path: 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 AC0C921F9F86 for ; Fri, 12 Jul 2013 07:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.035, 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 RCPdoKeggLxZ for ; Fri, 12 Jul 2013 07:37:11 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E856121F9AC4 for ; Fri, 12 Jul 2013 07:37:10 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so9041172pab.13 for ; Fri, 12 Jul 2013 07:37:10 -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=lf2g4pacBSFfZ8osAi03KsTgga0WzYj8Yvhx4/LFaro=; b=OZrJBKr6v8BmNhCwLOJdnx4NKQZ1N7G9AswV4PIcCc6G/HTOYUrkyTU9yDbnaxMOwq ZNV0MmVXTrKnlfN+Mi8zv6URu5yuGrej25KdoMo8FpLXatTSuRr4NqiPzvSiDR3E3dhz 5JOsUNI569PPuxQSMuHeHcHxWP0ECPWh0CsFubr44Pw+hiSyHlREPHmb2fMCynB7x5eR 9hp6hQ9JPZrK7W6Ytj+VhUZxTpToxdlX1kRdy0lgmZzsy03Dv0JQHKpCtTHAsx5zWgsk 33uTHKjl1n9AcSqy041XRW0kFtYltzwPABOY8/fT6Kru5/MYSMmpih8A9GYDhX7HL265 HqZw== 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=lf2g4pacBSFfZ8osAi03KsTgga0WzYj8Yvhx4/LFaro=; b=pneJ4HCiT13O+C7e9GjbKUq7sMI4FPS8WpvYMTFFj89EzK66x2bfEjHV+qkmWoos0Q QV62tPTrhuorr0WFMOLKJhyBLrDWzhXPeVZ5OE1z7ALA5yauPZSDIRkEiNuXrKp5o7Tv VoZkDEl4lKYbs689HJjmRkE+Lr6fCZ4zZtpsPcCyXWxj036i7pyVdtaad+XQl8Il7kVG eZtgjC/+gTAYGiEkLw2wITDqWoXIZO0XHWwbcf0mtkwFsdKoXRjPANfdsG0dQ0PvnmHE r3Fj0Q4DdqL0r/yFH1cO1l94VI+fPBFHk1BvJ8AF+QGyNWMubyo+Z2GLpfmA8zbYr/la Hl0w== X-Received: by 10.68.219.130 with SMTP id po2mr41932489pbc.54.1373639830523; Fri, 12 Jul 2013 07:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Fri, 12 Jul 2013 07:36:30 -0700 (PDT) In-Reply-To: References: <51DC3644.4020107@bbs.darktech.org> From: Peter Thatcher Date: Fri, 12 Jul 2013 07:36:30 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=e89a8ff2488125ead604e15172a5 X-Gm-Message-State: ALoCoQkepIVwodZWvq/eo7Xwz7DohCaerqwdg96fbaugdZxeI91ih/Rjqg79azit/qwnFR2hJu2khqvWWDGDy9BpdXumCR7gcyR9RJNzyZoXp8cVsOJjRJ5YN1cn6z+CDn4c1PYCbIrBVPzmMc4YldDdrSRLPLryBaG+y2is9HxkkP7CXq6dUCd/PvNPUpCSCou1tKijNj/n Cc: cowwoc , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 14:37:11 -0000 --e89a8ff2488125ead604e15172a5 Content-Type: text/plain; charset=UTF-8 A minor correction: I haven't engaged anyone on public-webrtc. I didn't even realize there were discussions going on over there about the API, since I wasn't keeping track and I thought they were all going on over here. Sorry about that. I guess I'll head over there and start engaging :). On Tue, Jul 9, 2013 at 1:40 PM, Eric Rescorla wrote: > > > > On Tue, Jul 9, 2013 at 9:11 AM, cowwoc wrote: > >> On 09/07/2013 11:33 AM, Ted Hardie wrote: >> >>> Howdy, >>> >>> The recent set of API discussions has been spread across both the rtcweb >>> and public-webrtc mailing lists. That's making it both harder to follow >>> and harder for folks to work out who is saying what under which rules. The >>> chairs of both groups believe that the right place for the discussion to >>> continue should be public-webrtc. Please direct follow-ups on this topic >>> to that list. >>> >>> regards, >>> >>> Ted Hardie >>> >> Ted, >> >> I agree, with one caveat: virtually none of the high-level >> stakeholders (spec editors, browser vendors, etc) bother to engage the >> community on public-webrtc. >> > > I'm not sure I understand this complaint. Is it that the aforementioned > "high-level stakeholders" > aren't engaging or merely that they are only engaging on RTCWEB? If it's > the former, than > I don't think that's actually true, since in the past week, you've had > responses from (at least) > the following people who fall into those categories: > > Cullen Jennings (spec editor) > Adam Bergqvist (spec editor) > Peter Thatcher (works on Chrome) > Me (works on Firefox and Chrome; spec editor) > Christer Holmberg (spec editor) > Several people from Microsoft. > > Who, exactly, are you expecting to engage that hasn't engaged? > > > If your complaint is just that they're engaging on the wrong mailing list, > well > that seems to reinforce Ted's point above. > > -Ekr > > > > > What's the point of discussing the API on this mailing list if our >> opinion goes unnoticed? We shouldn't be moving the discussion to >> public-webrtc as a nice way to filter us out. This discussion requires >> their attention, be it on one mailing list or the other. I don't mind where >> we discuss it, so long as they get involved. >> >> Is it their intention to get involved on public-webrtc and summarize >> the results on rtcweb? >> >> Thanks, >> Gili >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --e89a8ff2488125ead604e15172a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A minor correction: =C2=A0I haven't engaged anyone on = public-webrtc. =C2=A0I didn't even realize there were discussions going= on over there about the API, since I wasn't keeping track and I though= t they were all going on over here. =C2=A0Sorry about that. =C2=A0I guess I= 'll head over there and start engaging :).


On Tue, Jul 9= , 2013 at 1:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Tue, Jul 9, 2013 at 9:11 AM, cowwoc <c= owwoc@bbs.darktech.org> wrote:
On 09/07/2013 11:33 AM, Ted Hardie= wrote:
Howdy,

The recent set of API discussions has been spread across both the rtcweb an= d public-webrtc mailing lists. =C2=A0That's making it both harder to fo= llow and harder for folks to work out who is saying what under which rules.= =C2=A0The chairs of both groups believe that the right place for the discu= ssion to continue should be public-webrtc. =C2=A0Please direct follow-ups o= n this topic to that list.

regards,

Ted Hardie
Ted,

=C2=A0 =C2=A0 I agree, with one caveat: virtually none of the high-level st= akeholders (spec editors, browser vendors, etc) bother to engage the commun= ity on public-webrtc.

I'm not= sure I understand this complaint. Is it that the aforementioned "high= -level stakeholders"
aren't engaging or merely that they are only engaging on RTCWEB? I= f it's the former, than
I don't think that's actually= true, since in the past week, you've had responses from (at least)
the following people who fall into those categories:

Cullen Jennings (spec editor)
Adam Bergqvist (spec editor= )
Peter Thatcher (works on Chrome)
Me (works on Firefox= and Chrome; spec editor)
Christer Holmberg (spec editor)
Several people from Microsof= t.

Who, exactly, are you expecting to engage that = hasn't engaged?=C2=A0


If your complaint is just that they're engaging on = the wrong mailing list, well
that seems to reinforce Ted's po= int above.

-Ekr




=C2=A0 =C2=A0 What's the point of discussing the API on this mailing li= st if our opinion goes unnoticed? We shouldn't be moving the discussion= to public-webrtc as a nice way to filter us out. This discussion requires = their attention, be it on one mailing list or the other. I don't mind w= here we discuss it, so long as they get involved.

=C2=A0 =C2=A0 Is it their intention to get involved on public-webrtc and su= mmarize the results on rtcweb?

Thanks,
Gili



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


--e89a8ff2488125ead604e15172a5-- From fluffy@cisco.com Fri Jul 12 08:09:17 2013 Return-Path: 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 6494021F99A6 for ; Fri, 12 Jul 2013 08:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.554 X-Spam-Level: X-Spam-Status: No, score=-110.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 FxApEK4erTKq for ; Fri, 12 Jul 2013 08:09:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C135521F9635 for ; Fri, 12 Jul 2013 08:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2250; q=dns/txt; s=iport; t=1373641751; x=1374851351; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qcBrLm6tcLQSZ6ngkKfAVc8ZoeRGzkRJi2lAdeX3KNE=; b=VtiwDS5JHBYwo9O7wHyKwVHOGmdbnqxyhsEEsUOIVYm7oPwyzOelZU77 hZFkAMDMDLkfeA6qc7P5Nx01QrWNpvcD/vPuZP2LXMkpbC/Vx1sNEytiH MKmfyZg/F6NFvsXxeSH6PBJxm8nZRIsy4deNTgkBqhuzTFYJWmqd7rWcb Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAN8b4FGtJXG9/2dsb2JhbABagwaBA8FRgQkWdIIjAQEBAwE6PwULAgEIEQQBAQsUCQcyFAkIAgQOBQgTh24Gt1yPLgIxB4MLbAOpKYMSgig X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="234080689" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 12 Jul 2013 15:09:06 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6CF96R2023719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 15:09:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 10:09:05 -0500 From: "Cullen Jennings (fluffy)" To: "Hutton, Andrew" Thread-Topic: [rtcweb] Draft agenda for IETF 87 - FW Issues Thread-Index: AQHOft5ZQ5814mmC5UeNtbOepqDdYJlheZUA Date: Fri, 12 Jul 2013 15:09:05 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF116406C8@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF116406C8@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.76.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <57A2C1DA8156D3458F6286C5BF8EC9FE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 15:09:17 -0000 Can you get specific about exactly what you want to discuss? The current so= lution ins the specs uses ICE, STUN, TURN and works thorough many firewalls= but not all. What change would you like to see? On Jul 12, 2013, at 2:01 AM, "Hutton, Andrew" wrote: > Regarding the FW traversal discussion then I still think we need a discus= sion in the RTCWEB WG and I hope to persuade the chairs that this is the ca= se. > =20 > We have requirements in the use case draft and charter items that need so= lutions and this is a real issue impacting RTCWeb trials today. =20 > =20 > Regards > Andy > =20 > =20 > =20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Ted Hardie > Sent: 11 July 2013 17:51 > To: rtcweb@ietf.org > Cc: Cullen Jennings > Subject: [rtcweb] Draft agenda for IETF 87 > =20 > Greetings, >=20 > Below is an initial draft agenda for the upcoming meeting. Since we hav= e not yet reached the draft deadline (which is the 15th), there may be new = drafts or updates that result in changes. We did already receive requests = for NAT/Firewall traversal discussion, and the chairs will be working with = the document authors to get them considered in the appropriate groups. >=20 > As folks have probably noticed, we are meeting Thursday and Friday, after= the MMUSIC sessions are complete (they are Tuesday and Wednesday). This sh= ould allow us to discuss the results on our first day.=20 >=20 > Please send feedback or change proposals to the list. >=20 > thanks, >=20 > Ted and Cullen >=20 > Day 1: >=20 > Should SDES be part of WebRTC security practice and, if so, how? > Presentations: 30 minutes > Discussion: 40 minutes >=20 > Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents > Presentation: 30 minutes > Discussion: 30 minutes >=20 > Security document updates > Presentation: 10 minutes > Discussion: 10 minutes >=20 > Day 2: >=20 > Chair Discussion: 10 minutes >=20 > Use Case Requirements updates: > Issues list presentation: 20 minutes > Discussion: 20 minutes >=20 > Data channel: > Issues list presentation: 45 minutes > Discussion: 45 minutes >=20 >=20 From fluffy@cisco.com Fri Jul 12 08:17:02 2013 Return-Path: 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 81DB521F9A29 for ; Fri, 12 Jul 2013 08:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 4W7DpA5HUBKe for ; Fri, 12 Jul 2013 08:16:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CEF4A21F9F7B for ; Fri, 12 Jul 2013 08:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2495; q=dns/txt; s=iport; t=1373642217; x=1374851817; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O1a1jQE89ico0uCdhOD3COQnBukGmlEDGMnIXthWldE=; b=GB6mPRfd6KNAJxjVYRTD0hQZ5jQ6XNh/uLFSgnqADEUOj+3Hviw8ytnw 2oks33fUo1YYGNC0KlaDSXVWBiAkpJiL8MH+h2+0Db3oq+CcTWoX6Cwyk wEufG6xj5dstv3n7Sm0eugKDMYzChs2eQ61l9AFsb4ucGyT221djI4ufl 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngHAM4c4FGtJV2d/2dsb2JhbABagwZ3AQEKwVGBCRZ0giMBAQEDAXkQAgEIEQQBAQEKHQcyFAkIAgQOBQgTh24Gt1qPLgIxB4MLbAOpKYMSgig X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="234167028" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 12 Jul 2013 15:16:47 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6CFGlsX007822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 15:16:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 10:16:47 -0500 From: "Cullen Jennings (fluffy)" To: "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Draft agenda for IETF 87 - FW Issues Thread-Index: AQHOft5ZQ5814mmC5UeNtbOepqDdYA== Date: Fri, 12 Jul 2013 15:16:46 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF116406C8@MCHP04MSX.global-ad.net> <1EABABEB-CDCB-4D66-B201-AA19DA33407E@cisco.com> In-Reply-To: <1EABABEB-CDCB-4D66-B201-AA19DA33407E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.76.68] Content-Type: text/plain; charset="Windows-1252" Content-ID: <785EC896A38A3F48B4C2F44E5E19CAFD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 15:17:02 -0000 Andy, sorry =85 ignore this. I see you provided what I was asking for on an= other thread.=20 On Jul 12, 2013, at 8:09 AM, Cullen Jennings wrote: >=20 > Can you get specific about exactly what you want to discuss? The current = solution ins the specs uses ICE, STUN, TURN and works thorough many firewal= ls but not all. What change would you like to see? >=20 > On Jul 12, 2013, at 2:01 AM, "Hutton, Andrew" > wrote: >=20 >> Regarding the FW traversal discussion then I still think we need a discu= ssion in the RTCWEB WG and I hope to persuade the chairs that this is the c= ase. >>=20 >> We have requirements in the use case draft and charter items that need s= olutions and this is a real issue impacting RTCWeb trials today. =20 >>=20 >> Regards >> Andy >>=20 >>=20 >>=20 >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf= Of Ted Hardie >> Sent: 11 July 2013 17:51 >> To: rtcweb@ietf.org >> Cc: Cullen Jennings >> Subject: [rtcweb] Draft agenda for IETF 87 >>=20 >> Greetings, >>=20 >> Below is an initial draft agenda for the upcoming meeting. Since we ha= ve not yet reached the draft deadline (which is the 15th), there may be new= drafts or updates that result in changes. We did already receive requests= for NAT/Firewall traversal discussion, and the chairs will be working with= the document authors to get them considered in the appropriate groups. >>=20 >> As folks have probably noticed, we are meeting Thursday and Friday, afte= r the MMUSIC sessions are complete (they are Tuesday and Wednesday). This s= hould allow us to discuss the results on our first day.=20 >>=20 >> Please send feedback or change proposals to the list. >>=20 >> thanks, >>=20 >> Ted and Cullen >>=20 >> Day 1: >>=20 >> Should SDES be part of WebRTC security practice and, if so, how? >> Presentations: 30 minutes >> Discussion: 40 minutes >>=20 >> Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents >> Presentation: 30 minutes >> Discussion: 30 minutes >>=20 >> Security document updates >> Presentation: 10 minutes >> Discussion: 10 minutes >>=20 >> Day 2: >>=20 >> Chair Discussion: 10 minutes >>=20 >> Use Case Requirements updates: >> Issues list presentation: 20 minutes >> Discussion: 20 minutes >>=20 >> Data channel: >> Issues list presentation: 45 minutes >> Discussion: 45 minutes >>=20 >>=20 >=20 From andrew.hutton@siemens-enterprise.com Fri Jul 12 08:18:00 2013 Return-Path: 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 7B6C811E8117 for ; Fri, 12 Jul 2013 08:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 dzyzGq6gEsRi for ; Fri, 12 Jul 2013 08:17:53 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AD9BB21F9FF7 for ; Fri, 12 Jul 2013 08:17:52 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id DAA1223F058F; Fri, 12 Jul 2013 17:17:49 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Fri, 12 Jul 2013 17:17:49 +0200 From: "Hutton, Andrew" To: "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Draft agenda for IETF 87 - FW Issues Thread-Index: AQHOflbuioJxfw6BTUiF3V93e/1K7plguuEQgABKaYCAACHmgA== Date: Fri, 12 Jul 2013 15:17:49 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1164151F@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF116406C8@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 15:18:00 -0000 What we want to discuss is a solution to the HTTP (Proxy) only FW use case = as described in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-= requirements-11#section-3.2.3. This is not solved by the current specs.=20 The draft http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consi= derations-01 proposes a solution based on using HTTP Connect and some other= related browser best practice requirements but also discusses alternatives= . We want to discuss solving this use case and hopefully get this draft adopt= ed. Andy > -----Original Message----- > From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > Sent: 12 July 2013 16:09 > To: Hutton, Andrew > Cc: Ted Hardie; rtcweb@ietf.org > Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues >=20 >=20 > Can you get specific about exactly what you want to discuss? The > current solution ins the specs uses ICE, STUN, TURN and works thorough > many firewalls but not all. What change would you like to see? >=20 > On Jul 12, 2013, at 2:01 AM, "Hutton, Andrew" enterprise.com> > wrote: >=20 > > Regarding the FW traversal discussion then I still think we need a > discussion in the RTCWEB WG and I hope to persuade the chairs that this > is the case. > > > > We have requirements in the use case draft and charter items that > need solutions and this is a real issue impacting RTCWeb trials today. > > > > Regards > > Andy > > > > > > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Ted Hardie > > Sent: 11 July 2013 17:51 > > To: rtcweb@ietf.org > > Cc: Cullen Jennings > > Subject: [rtcweb] Draft agenda for IETF 87 > > > > Greetings, > > > > Below is an initial draft agenda for the upcoming meeting. Since we > have not yet reached the draft deadline (which is the 15th), there may > be new drafts or updates that result in changes. We did already > receive requests for NAT/Firewall traversal discussion, and the chairs > will be working with the document authors to get them considered in the > appropriate groups. > > > > As folks have probably noticed, we are meeting Thursday and Friday, > after the MMUSIC sessions are complete (they are Tuesday and > Wednesday). This should allow us to discuss the results on our first > day. > > > > Please send feedback or change proposals to the list. > > > > thanks, > > > > Ted and Cullen > > > > Day 1: > > > > Should SDES be part of WebRTC security practice and, if so, how? > > Presentations: 30 minutes > > Discussion: 40 minutes > > > > Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents > > Presentation: 30 minutes > > Discussion: 30 minutes > > > > Security document updates > > Presentation: 10 minutes > > Discussion: 10 minutes > > > > Day 2: > > > > Chair Discussion: 10 minutes > > > > Use Case Requirements updates: > > Issues list presentation: 20 minutes > > Discussion: 20 minutes > > > > Data channel: > > Issues list presentation: 45 minutes > > Discussion: 45 minutes > > > > From fluffy@cisco.com Fri Jul 12 08:30:57 2013 Return-Path: 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 E941121F9BB9 for ; Fri, 12 Jul 2013 08:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.558 X-Spam-Level: X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 rygQPZrLch6A for ; Fri, 12 Jul 2013 08:30:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF2F11E8121 for ; Fri, 12 Jul 2013 08:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4632; q=dns/txt; s=iport; t=1373643038; x=1374852638; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EWkr6zbckM3UPAi8KvipLzLDh+D8koRY63JKTCaHRoE=; b=HNoemkEQUfuIHg+57AZocOpH99VApvP65iDygpfuhXZoMfPpoTY11FCF eWI1i0m6YhgX//wTSYtN0jbamWOaeoqcBVzeTMzD0EubdohTxgte4Z0zU SfPAfT82S1DGNcRAO67VyB+iOGf7YVkd5PXeaUf1+if7G6GvRSTfxR033 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAMgg4FGtJXG8/2dsb2JhbABagwY0T8FRgQkWdIIjAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIE4duBgy3Uo8uAjEHBoMFbAOZBZAkgxKCKA X-IronPort-AV: E=Sophos;i="4.89,653,1367971200"; d="scan'208";a="234114043" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 12 Jul 2013 15:30:38 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6CFUbqd021843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 15:30:38 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 10:30:37 -0500 From: "Cullen Jennings (fluffy)" To: "Hutton, Andrew" Thread-Topic: [rtcweb] Draft agenda for IETF 87 - FW Issues Thread-Index: AQHOft5ZQ5814mmC5UeNtbOepqDdYJlguuEQgABKaYCAACHmgIAAWGiA Date: Fri, 12 Jul 2013 15:30:36 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF116406C8@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1164151F@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1164151F@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.76.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <73E293AAE7ABBC489E6019F895C017B1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 15:30:57 -0000 So section 3.3.1 of draft-hutton-rtcweb-nat-firewall-considerations provide= s a brief sketch of an extension to TURN clients to use a HTTP proxy.=20 I would be shocked to see anyone in this WG tell you not to do that, it's b= een discussed many times in the past. But in the end this WG will either sa= y we like it, take it to BEHAVE, or it will say we hate it in which case as= and individual draft you will still probably take it to BEHAVE. You probab= ly want to keep an eye on HTTP2 stuff and implications to this too.=20 We had not much list discussion on this draft. We have an agenda very full = of WG items that are very controversial. We could put it at the end of the = agenda with "time permitting" but to be honest, I sort of doubt we would ge= t to it. Is there some question you think you want feedback from this group= on that we could start on this list or something?=20 I'm just trying to be realistic about the outcomes of this draft - we could= discuss it in RTCWeb for 3 meetings before proposing a TURN extension in = behave but in the end I suspect we could just short circuit all that.=20 On Jul 12, 2013, at 8:17 AM, "Hutton, Andrew" wrote: > What we want to discuss is a solution to the HTTP (Proxy) only FW use cas= e as described in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-an= d-requirements-11#section-3.2.3. This is not solved by the current specs.=20 >=20 > The draft http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-con= siderations-01 proposes a solution based on using HTTP Connect and some oth= er related browser best practice requirements but also discusses alternativ= es. >=20 > We want to discuss solving this use case and hopefully get this draft ado= pted. >=20 > Andy >=20 >=20 >=20 >> -----Original Message----- >> From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] >> Sent: 12 July 2013 16:09 >> To: Hutton, Andrew >> Cc: Ted Hardie; rtcweb@ietf.org >> Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues >>=20 >>=20 >> Can you get specific about exactly what you want to discuss? The >> current solution ins the specs uses ICE, STUN, TURN and works thorough >> many firewalls but not all. What change would you like to see? >>=20 >> On Jul 12, 2013, at 2:01 AM, "Hutton, Andrew" > enterprise.com> >> wrote: >>=20 >>> Regarding the FW traversal discussion then I still think we need a >> discussion in the RTCWEB WG and I hope to persuade the chairs that this >> is the case. >>>=20 >>> We have requirements in the use case draft and charter items that >> need solutions and this is a real issue impacting RTCWeb trials today. >>>=20 >>> Regards >>> Andy >>>=20 >>>=20 >>>=20 >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Ted Hardie >>> Sent: 11 July 2013 17:51 >>> To: rtcweb@ietf.org >>> Cc: Cullen Jennings >>> Subject: [rtcweb] Draft agenda for IETF 87 >>>=20 >>> Greetings, >>>=20 >>> Below is an initial draft agenda for the upcoming meeting. Since we >> have not yet reached the draft deadline (which is the 15th), there may >> be new drafts or updates that result in changes. We did already >> receive requests for NAT/Firewall traversal discussion, and the chairs >> will be working with the document authors to get them considered in the >> appropriate groups. >>>=20 >>> As folks have probably noticed, we are meeting Thursday and Friday, >> after the MMUSIC sessions are complete (they are Tuesday and >> Wednesday). This should allow us to discuss the results on our first >> day. >>>=20 >>> Please send feedback or change proposals to the list. >>>=20 >>> thanks, >>>=20 >>> Ted and Cullen >>>=20 >>> Day 1: >>>=20 >>> Should SDES be part of WebRTC security practice and, if so, how? >>> Presentations: 30 minutes >>> Discussion: 40 minutes >>>=20 >>> Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents >>> Presentation: 30 minutes >>> Discussion: 30 minutes >>>=20 >>> Security document updates >>> Presentation: 10 minutes >>> Discussion: 10 minutes >>>=20 >>> Day 2: >>>=20 >>> Chair Discussion: 10 minutes >>>=20 >>> Use Case Requirements updates: >>> Issues list presentation: 20 minutes >>> Discussion: 20 minutes >>>=20 >>> Data channel: >>> Issues list presentation: 45 minutes >>> Discussion: 45 minutes >>>=20 >>>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Fri Jul 12 09:04:59 2013 Return-Path: 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 C67B411E80FE for ; Fri, 12 Jul 2013 09:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 h3zN-Hh6jgQr for ; Fri, 12 Jul 2013 09:04:59 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2482121F9A74 for ; Fri, 12 Jul 2013 09:04:58 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id c11so8173917wgh.13 for ; Fri, 12 Jul 2013 09:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0S7snr5tTyCujx3f0Kq7OuAXK6R2xUenAoBamLBOgQg=; b=Kkd0RhkB8y54gvWUfazT1rh0U+5TrtZhmcWtrQGxlYcC+0lA9LPssZyL3jLgcgbIE5 hOQNp3NDUR8XeMh7V7d1dkPDaCGxhFAnmZZy+GHfdCG1HybVDl1fE7NZEyXwNGmQlExu c+v3EY8gOZNzytn9EoI7tuCWaW041l30Xm2ECRP90W5/0VCqVm3wyrcovhOGL5vi3d0O K6q4HDCJHup3UWX9a6TRlJW8AE27FPo26T5h9RhfwL/Pq7r6h9UwM3RU0uSnf9DmKtO6 AadwmWLfiGeU0BQkLuEQguTDBQpilkXAFdEhxWe8NZ9ZoZuENMh2Zgbb4nX4Xs8WRV6n n1gw== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr24680261wjx.84.1373645098288; Fri, 12 Jul 2013 09:04:58 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 12 Jul 2013 09:04:58 -0700 (PDT) Date: Fri, 12 Jul 2013 09:04:58 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] division of responsibilities (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 16:04:59 -0000 On 12 July 2013 00:35, Stefan H=C3=A5kansson LK wrote: > To me it seems pretty straightforward to a certain point: > > * The SDP (if we opt to continue using SDP for this purpose) that goes > on the signaling wire between the browsers is defined by IETF (and by > the rtcweb WG I presume even though MMUSIC seems to have some stake) > > * JS APIs to: > ** Apply an SDP (e.g. received on the signaling channel) to the browser > ** Hand an SDP generated by the browser over to the application (for > transmission over the signaling wire presumably) > ** Influencing/modifying the contents of the SDP > * All belongs to the W3C WebRTC > > What seems unclear to me is where we define what modifications to the > SDP that are allowed - and when. Even though the ambition is to have > APIs that makes SDP mangling an exception, we will still see that > happening. I can see how you would reach that conclusion, but it's only simple at the most superficial level. There needs to be a clear understanding about what information is carried in SDP and what information is supplied by the application. I have observed that there is an assumption implicit in a lot of the work that says that SDP carries everything it can possibly carry. I'll note that this has been implicit, never explicit. And the mere existence of no-plan highlights the fact that there is a fundamental disagreement on this point. We've been building a consensus that is based on an assumption. I'd rather we had consensus than an untested assumption. With all respect to the chairs, that's not something I trust them to rule on at this point. From andrew.hutton@siemens-enterprise.com Fri Jul 12 09:44:25 2013 Return-Path: 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 8A1D811E8150 for ; Fri, 12 Jul 2013 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 eJcpVWnO9yfw for ; Fri, 12 Jul 2013 09:44:20 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6C78121F9F71 for ; Fri, 12 Jul 2013 09:44:18 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 87FCA23F0585; Fri, 12 Jul 2013 18:44:15 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Fri, 12 Jul 2013 18:44:15 +0200 From: "Hutton, Andrew" To: "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Draft agenda for IETF 87 - FW Issues Thread-Index: AQHOflbuioJxfw6BTUiF3V93e/1K7plguuEQgABKaYCAACHmgP//5B0AgAAx4TA= Date: Fri, 12 Jul 2013 16:44:14 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF11641905@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF116406C8@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1164151F@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 16:44:25 -0000 I totally don't follow this argument. What we need is for RTCWEB browsers to behave in a standardized way in envi= ronments where there is a FW requiring the flow to come from a HTTP Proxy. = Defining this is clearly within the scope of RTCWEB and if we move the work= to BEHAVE we still need a RTCWEB specification to say what rtcweb implemen= tations are required to implement. The charter states the wg will. "Define the solution - protocols and API requirements - for firewall and NA= T traversal". It also states: "This work will be done primarily by using already defined protocols or fun= ctionalities. If there is identification of missing protocols or functional= ities, such work can be requested to be done in another working group with = a suitable charter or by requests for chartering it in this WG or another W= G". We have not so far identified any missing protocol or functionality so why = do you ask the work to be moved to a different group? With regard to the full agenda I for one think we can find time for this ra= ther than again circling through the endless discussion on some of the othe= r topics. I am not sure also why we need 40 mins to discuss the use case up= dates time would be better spent finding solutions for the existing use cas= es. If you think that nobody will object then surely we can get this over very = quickly. Agree there has not been enough discussion on the draft but I have received= only positive feedback including some comments off list. Regards Andy > -----Original Message----- > From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > Sent: 12 July 2013 16:31 > To: Hutton, Andrew > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues >=20 >=20 > So section 3.3.1 of draft-hutton-rtcweb-nat-firewall-considerations > provides a brief sketch of an extension to TURN clients to use a HTTP > proxy. >=20 > I would be shocked to see anyone in this WG tell you not to do that, > it's been discussed many times in the past. But in the end this WG will > either say we like it, take it to BEHAVE, or it will say we hate it in > which case as and individual draft you will still probably take it to > BEHAVE. You probably want to keep an eye on HTTP2 stuff and > implications to this too. >=20 > We had not much list discussion on this draft. We have an agenda very > full of WG items that are very controversial. We could put it at the > end of the agenda with "time permitting" but to be honest, I sort of > doubt we would get to it. Is there some question you think you want > feedback from this group on that we could start on this list or > something? >=20 > I'm just trying to be realistic about the outcomes of this draft - we > could discuss it in RTCWeb for 3 meetings before proposing a TURN > extension in behave but in the end I suspect we could just short > circuit all that. >=20 >=20 > On Jul 12, 2013, at 8:17 AM, "Hutton, Andrew" enterprise.com> wrote: >=20 > > What we want to discuss is a solution to the HTTP (Proxy) only FW use > case as described in http://tools.ietf.org/html/draft-ietf-rtcweb-use- > cases-and-requirements-11#section-3.2.3. This is not solved by the > current specs. > > > > The draft http://tools.ietf.org/html/draft-hutton-rtcweb-nat- > firewall-considerations-01 proposes a solution based on using HTTP > Connect and some other related browser best practice requirements but > also discusses alternatives. > > > > We want to discuss solving this use case and hopefully get this draft > adopted. > > > > Andy > > > > > > > >> -----Original Message----- > >> From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > >> Sent: 12 July 2013 16:09 > >> To: Hutton, Andrew > >> Cc: Ted Hardie; rtcweb@ietf.org > >> Subject: Re: [rtcweb] Draft agenda for IETF 87 - FW Issues > >> > >> > >> Can you get specific about exactly what you want to discuss? The > >> current solution ins the specs uses ICE, STUN, TURN and works > thorough > >> many firewalls but not all. What change would you like to see? > >> > >> On Jul 12, 2013, at 2:01 AM, "Hutton, Andrew" > >> enterprise.com> > >> wrote: > >> > >>> Regarding the FW traversal discussion then I still think we need a > >> discussion in the RTCWEB WG and I hope to persuade the chairs that > this > >> is the case. > >>> > >>> We have requirements in the use case draft and charter items that > >> need solutions and this is a real issue impacting RTCWeb trials > today. > >>> > >>> Regards > >>> Andy > >>> > >>> > >>> > >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Ted Hardie > >>> Sent: 11 July 2013 17:51 > >>> To: rtcweb@ietf.org > >>> Cc: Cullen Jennings > >>> Subject: [rtcweb] Draft agenda for IETF 87 > >>> > >>> Greetings, > >>> > >>> Below is an initial draft agenda for the upcoming meeting. Since > we > >> have not yet reached the draft deadline (which is the 15th), there > may > >> be new drafts or updates that result in changes. We did already > >> receive requests for NAT/Firewall traversal discussion, and the > chairs > >> will be working with the document authors to get them considered in > the > >> appropriate groups. > >>> > >>> As folks have probably noticed, we are meeting Thursday and Friday, > >> after the MMUSIC sessions are complete (they are Tuesday and > >> Wednesday). This should allow us to discuss the results on our first > >> day. > >>> > >>> Please send feedback or change proposals to the list. > >>> > >>> thanks, > >>> > >>> Ted and Cullen > >>> > >>> Day 1: > >>> > >>> Should SDES be part of WebRTC security practice and, if so, how? > >>> Presentations: 30 minutes > >>> Discussion: 40 minutes > >>> > >>> Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents > >>> Presentation: 30 minutes > >>> Discussion: 30 minutes > >>> > >>> Security document updates > >>> Presentation: 10 minutes > >>> Discussion: 10 minutes > >>> > >>> Day 2: > >>> > >>> Chair Discussion: 10 minutes > >>> > >>> Use Case Requirements updates: > >>> Issues list presentation: 20 minutes > >>> Discussion: 20 minutes > >>> > >>> Data channel: > >>> Issues list presentation: 45 minutes > >>> Discussion: 45 minutes > >>> > >>> > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From pthatcher@google.com Fri Jul 12 10:19:50 2013 Return-Path: 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 1F55B21E80B2 for ; Fri, 12 Jul 2013 10:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 pyIxa4jp84NL for ; Fri, 12 Jul 2013 10:19:49 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id BAEAD21E80B6 for ; Fri, 12 Jul 2013 10:19:48 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so8727246pdi.11 for ; Fri, 12 Jul 2013 10:19:46 -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=mAw9IPK2qxXxr/TUL+PwcAvoMb2dJJ7b+5DlvnQhm/I=; b=pKR8h2RVTOmBII5l/oAQsNybSjVOK9zmi8UCe1mCmaD1ZOZcnejlBsVbozc3tCHilt FHcLmg0FTZ6+UjgFiGTznuy9u5S6d3i+0X46Mf+SvMb4nPmCrE1ksQX+I+kv0tAfWZKW 6mi9t36Uk9EXT0CMLhzoHwU4xv/GyBPuDdOlKLITceMxII4AHJY5V7usAw+n27Qxa9zQ Un+pP7K/0MVrRcOrl99BXpwcvrvd6FyCuSyKTvcSGyQ0ZOscMUmgqGyRrSdkgvQ/TdPr T8rKFlhKFcRjPVsCIFaY6bJUZfyxOp/7kuMdV80ieBKQCstRYiPzFwvPXfx2FPijz6sH GHww== 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=mAw9IPK2qxXxr/TUL+PwcAvoMb2dJJ7b+5DlvnQhm/I=; b=HkrVGQ4ZuWL2uqLuRjvKNMIAhKpSmnyzLjbUR+KiAzl1wuMcVxOqogJ9rUOQeLvsZa RdR3Dip8vEB08r8GrVOTQIoFDiJrTrB9lj8rM9WFAJEKUyuY8BLVv0NAjOCMQhQSK3LU SyX6k8uM7iu6JXO+5jHbXjxthGHl/IyIbrMrWL3AajmqTmFWi39R4w2MOh734+4w+lzm OgX1hwnVbRJTgBGPPrTodlfbPu72gAKCi4+ip+/zDzevZVmZ3WJvoBbG0cx7ju8q7x/3 DWyqo/ro/9/UrCxx7H74jr+1txtzq20Ph9CsPFLIOBLq8szx/gWABagWYPCHUfoG/OHQ pdMw== X-Received: by 10.68.213.5 with SMTP id no5mr42825743pbc.185.1373649586660; Fri, 12 Jul 2013 10:19:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Fri, 12 Jul 2013 10:19:06 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C311367@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C311367@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Fri, 12 Jul 2013 10:19:06 -0700 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=e89a8fb20834a8c89004e153b7e7 X-Gm-Message-State: ALoCoQmqZTKF9CXfnR5mCng4lpnjLTC4j5Wrk0E1Ru7pP1izgNjdcNH7f6KVtxDCDxj8Xyt6+DzKkOBNANoYWj/MUnHtmYQd39mCy/uSJ2qgaff2ocI/2nGXnChT/NlbHC+VXqBidVFTPuDE/j20K3gO3iTzhVZ6eYy3GPdpav6GKRnp8/Hzw5/WTjaDoneHRot+hxe0TdvI Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:19:50 -0000 --e89a8fb20834a8c89004e153b7e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 12:35 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 7/11/13 9:38 PM, Martin Thomson wrote: > > On 11 July 2013 12:04, Cullen Jennings (fluffy) > > wrote: > >> On Jul 11, 2013, at 10:35 AM, Emil Ivov > >>> In you last mail on the subject you mentioned that we will be > >>> discussing No Plan in Berlin together with plans A and B. Could > >>> we please add this to the agenda? > >> > >> No. We believe that conversation needs to happen in the W3C WebRTC > >> WG. I expect to see a message from W3C chairs on this at some > >> point. > > > > I'm a little nervous about this. Where does the decision on the > > separation of responsibilities (API vs. SDP) get made? > > (I have not been able to confer with any of the other chairs, so this is > just my personal opinion): > > To me it seems pretty straightforward to a certain point: > > * The SDP (if we opt to continue using SDP for this purpose) that goes > on the signaling wire between the browsers is defined by IETF (and by > the rtcweb WG I presume even though MMUSIC seems to have some stake) > > * JS APIs to: > ** Apply an SDP (e.g. received on the signaling channel) to the browser > ** Hand an SDP generated by the browser over to the application (for > transmission over the signaling wire presumably) > ** Influencing/modifying the contents of the SDP > * All belongs to the W3C WebRTC > Would it make sense to change this list to say the following? * JS APIs to: ** Apply a SessionDescription (created by SDP; eg received on the signaling channel or built by JS) to the browser ** Hand a SessionDescription (serializable to SDP) generated by the browser over to the application (for transmission over the signaling wire presumably or for immediately applying with setLocalDescription for some local effect) ** Influencing/modifying the contents of the SessionDescription (and thus, SDP, when serialized to SDP) * All belongs to the W3C WebRTC My changes highlight a few things: 1. The API (setLocalDescripiton, setRemoteDescription, creatOffer, etc) doesn't work with SDP directly. It works with RTCSessionDescription objects. It just happens to be that currently the only way to interact with RTCSessionDescription objects is through SDP. I think it's worth remembering that distinction. 2. SDP does not necessarily go over the wire. It only necessarily goes through the API between JS and browser. I think it's worth remembering that distinction. 3. Calling setLocalDescription with a new SessionDescription object can have purely local effects that don't need to be sent over the wire. I think it's worth remembering those cases. > > What seems unclear to me is where we define what modifications to the > SDP that are allowed - and when. Even though the ambition is to have > APIs that makes SDP mangling an exception, we will still see that > happening. > I think advanced JS apps are going to use every control knob they can get to, whether it's anticipated and well-supported or not. I think there's a good chance that a a popular WebRTC web app will use some SDP mangling that wasn't anticipated, but happened to work, but then the browser can't remove it because it will break certain websites. It could get even worse if someone writes a popular WebRTC wrapper library that uses tricky SDP mangling that is then used by lots of websites. Certain SDP mangling techniques might end up becoming a defacto standard API that can't be removed, even if it was originally a bug. Or worse, one browser will have to implement the SDP mangling or even the bugs of another, because WebRTC apps have come to rely on them. In fact, it's already the case that Chrome and Firefox support far different SDP manglings. I don't think any web apps rely on that yet, but it's only a matter of time before someone figures out "hey, if I mangle the SDP on this browser this way and on that browser that way, I can do things I couldn't do otherwise". Or worse, an advanced web app developer says "hey, I can make this work well on browser X via SDP mangling, but not on browser Y, so I'll put a 'best used with Browser X' icon on my website". Then that someone writes an abstraction on top of that, and then maybe shares that with others, and it goes from there. I think we're in a race with web developers to see if they'll figure out SDP mangling before we provide a way to avoid SDP mangling. Who do you think moves faster? > > > _______________________________________________ rtcweb mailing list > > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --e89a8fb20834a8c89004e153b7e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 12, 2013 at 12:35 AM, Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
On 7/11/13 9:38 PM, Martin Thomson wrote= :
> On 11 July 2013 12:04, Cullen Jennings (fluffy) <fluffy@cisco.com>
> wrote:
>> On Jul 11, 2013, at 10:35 AM, Emil Ivov <emcho@jitsi.org>
>>> In you last mail on the subject you mentioned that we will be<= br> >>> discussing No Plan in Berlin together with plans A and B. Coul= d
>>> we please add this to the agenda?
>>
>> No. We believe that conversation needs to happen in the W3C WebRTC=
>> WG. I expect to see a message from W3C chairs on this at some
>> point.
>
> I'm a little nervous about this. =C2=A0Where does the decision on = the
> separation of responsibilities (API vs. SDP) get made?

(I have not been able to confer with any of the other chairs, so this= is
just my personal opinion):

To me it seems pretty straightforward to a certain point:

* The SDP (if we opt to continue using SDP for this purpose) that goes
on the signaling wire between the browsers is defined by IETF (and by
the rtcweb WG I presume even though MMUSIC seems to have some stake)

* JS APIs to:
** Apply an SDP (e.g. received on the signaling channel) to the browser
** Hand an SDP generated by the browser over to the application (for
transmission over the signaling wire presumably)
** Influencing/modifying the contents of the SDP
* All belongs to the W3C WebRTC

Would i= t make sense to change this list to say the following?

=
* JS APIs to:
** Apply a SessionDescription (created by SDP; eg rec= eived on the signaling channel or built by JS) to the browser
** Hand a SessionDescription (serializable to SDP) generated by the br= owser over to the application (for
transmission over the signaling wire = presumably or for immediately applying with setLocalDescription for some lo= cal effect)
** Influencing/modifying the contents of the SessionDescription (and thus, = SDP, when serialized to SDP)
* All belongs to the W3C WebRTC


My changes highlight a few things:
1. =C2=A0The API (setLocalDescripiton, setRemoteDescription, creatOffe= r, etc) doesn't work with SDP directly. =C2=A0It works with RTCSessionD= escription objects. =C2=A0It just happens to be that currently the only way= to interact with RTCSessionDescription objects is through SDP. =C2=A0I thi= nk it's worth remembering that distinction. =C2=A0

2. =C2=A0SDP does not necessarily go over the wire. =C2= =A0 It only necessarily goes through the API between JS and browser. =C2=A0= I think it's worth remembering that distinction. =C2=A0

=
3. =C2=A0Calling setLocalDescription with a new SessionDescripti= on object can have purely local effects that don't need to be sent over= the wire. =C2=A0I think it's worth remembering those cases. =C2=A0

=C2=A0

What seems unclear to me is where we define what modifications to the
SDP that are allowed - and when. Even though the ambition is to have
APIs that makes SDP mangling an exception, we will still see that
happening.

I think advanced JS apps are= going to use every control knob they can get to, whether it's anticipa= ted and well-supported or not. =C2=A0 =C2=A0I think there's a good chan= ce that a a popular WebRTC web app will use some SDP mangling that wasn'= ;t anticipated, but happened to work, but then the browser can't remove= it because it will break certain websites. =C2=A0It could get even worse i= f someone writes a popular WebRTC wrapper library that uses tricky SDP mang= ling that is then used by lots of websites. =C2=A0Certain SDP mangling tech= niques might end up becoming a defacto standard API that can't be remov= ed, even if it was originally a bug. =C2=A0Or worse, one browser will have = to implement the SDP mangling or even the bugs of another, because WebRTC a= pps have come to rely on them.

In fact, it's already the case that Chrome and Fire= fox support far different SDP manglings. =C2=A0I don't think any web ap= ps rely on that yet, but it's only a matter of time before someone figu= res out "hey, if I mangle the SDP on this browser this way and on that= browser that way, I can do things I couldn't do otherwise". =C2= =A0Or worse, an advanced web app developer says "hey, I can make this = work well on browser X via SDP mangling, but not on browser Y, so I'll = put a 'best used with Browser X' icon on my website". Then tha= t someone writes an abstraction on top of that, and then maybe shares that = with others, and it goes from there. =C2=A0

I think we're in a race with web developers to see = if they'll figure out SDP mangling before we provide a way to avoid SDP= mangling. =C2=A0 Who do you think moves faster?

<= br>



=C2=A0

=C2=A0

> _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.iet= f.org/mailman/listinfo/rtcweb
>

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

--e89a8fb20834a8c89004e153b7e7-- From stefan.lk.hakansson@ericsson.com Fri Jul 12 10:27:54 2013 Return-Path: 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 5F09521F9E40 for ; Fri, 12 Jul 2013 10:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.213 X-Spam-Level: X-Spam-Status: No, score=-5.213 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 Zu9JzjRXAmfH for ; Fri, 12 Jul 2013 10:27:48 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AC28C21F9FEA for ; Fri, 12 Jul 2013 10:27:47 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-df-51e03c8f0e14 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DD.3B.05990.F8C30E15; Fri, 12 Jul 2013 19:27:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 19:27:43 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Martin Thomson Thread-Topic: division of responsibilities (was: Draft agenda for IETF 87) Thread-Index: AQHOfxmP+iu/sYlzgUm8j1W7o4aRzQ== Date: Fri, 12 Jul 2013 17:27:43 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3128C7@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvrW6/zYNAg1P9ShYdk9ksrp35x2ix 9l87uwOzx5TfG1k9ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6M7r/WBf8EK1b8u8fawLib r4uRg0NCwERixkqjLkZOIFNM4sK99WxdjFwcQgKHGSV2Xb4B5SxilJjfsoUFpIpNIFBi674F bCC2iICuxKKzD9hBbGaBKIkdm3qYQGxhAU+JZ3+eMUHUeEls+dvCDmHrSeyaMo8ZxGYRUJVY OeM8I4jNK+Ar0XPqKiuILSQQILFxzgOw+YxAF30/tYYJYr64xK0n85kgLhWQWLLnPDOELSrx 8vE/VghbSeLHhkssEPV6EjemTmGDsLUlli18zQyxS1Di5MwnLBMYRWchGTsLScssJC2zkLQs YGRZxciem5iZk15utIkRGBsHt/xW3cF455zIIUZpDhYlcd7NemcChQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTCmmfxK/H3jju5kvksuu1YoGjqeuLnjauir80w/Fl6byG/Ifydo1c7i5OnC 2RK7TuTtM8vQbChLz75z+s/jBkEttm0OFtLWu7NXWK3762Ge8SH12L8o1v67Uw+JNOSy9qRp Vk2fXxqTsatu9poAWd3s6bmGf8/EBzDtq5++9Xgrh92n/T9+3t6qxFKckWioxVxUnAgArBh1 bVsCAAA= Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] division of responsibilities (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:27:54 -0000 On 7/12/13 6:04 PM, Martin Thomson wrote:=0A= > On 12 July 2013 00:35, Stefan H=E5kansson LK=0A= > wrote:=0A= >> To me it seems pretty straightforward to a certain point:=0A= >>=0A= >> * The SDP (if we opt to continue using SDP for this purpose) that goes= =0A= >> on the signaling wire between the browsers is defined by IETF (and by=0A= >> the rtcweb WG I presume even though MMUSIC seems to have some stake)=0A= >>=0A= >> * JS APIs to:=0A= >> ** Apply an SDP (e.g. received on the signaling channel) to the browser= =0A= >> ** Hand an SDP generated by the browser over to the application (for=0A= >> transmission over the signaling wire presumably)=0A= >> ** Influencing/modifying the contents of the SDP=0A= >> * All belongs to the W3C WebRTC=0A= >>=0A= >> What seems unclear to me is where we define what modifications to the=0A= >> SDP that are allowed - and when. Even though the ambition is to have=0A= >> APIs that makes SDP mangling an exception, we will still see that=0A= >> happening.=0A= >=0A= > I can see how you would reach that conclusion, but it's only simple at=0A= > the most superficial level.=0A= >=0A= > There needs to be a clear understanding about what information is=0A= > carried in SDP and what information is supplied by the application. I=0A= > have observed that there is an assumption implicit in a lot of the=0A= > work that says that SDP carries everything it can possibly carry.=0A= > I'll note that this has been implicit, never explicit. And the mere=0A= > existence of no-plan highlights the fact that there is a fundamental=0A= > disagreement on this point.=0A= =0A= This is a very good point IMO. You have brought it up before, and I =0A= think it is very valid. We need to decide what info is carried over=0A= =0A= * in SDP (if SDP is kept)=0A= * in RTP/RTCP=0A= * in any other means we standardize=0A= =0A= and what is supplied by the application.=0A= =0A= >=0A= > We've been building a consensus that is based on an assumption. I'd=0A= > rather we had consensus than an untested assumption. With all respect=0A= > to the chairs, that's not something I trust them to rule on at this=0A= > point.=0A= =0A= FWIW, I agree. This needs more discussion.=0A= =0A= >=0A= =0A= From pthatcher@google.com Fri Jul 12 10:32:38 2013 Return-Path: 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 BD7DD11E811E for ; Fri, 12 Jul 2013 10:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 pe4ZJ3wzgPFx for ; Fri, 12 Jul 2013 10:32:38 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 03CF421F9A05 for ; Fri, 12 Jul 2013 10:32:37 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id 14so8729407pdj.40 for ; Fri, 12 Jul 2013 10:32:37 -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=9WLuBTRuBUsHt7celv30OZ0xH9Zz2VNAqw+Rg6atRTA=; b=R08mqqKnLSniQxl/Wl1n7sdJcyifdrx/72Hpv+5iPmwlrJFmFRpbYRdRZaa93A5oy2 eGAgY4sTvzaGdRILM9lQQXVyocEpaLiWjKqeAS5RgmmNFPXLF71zzt9epjwuQyEgrFZG IAJKWKzbGV6Qlwt3L6+B48YWAFcTqAJ4Ry4OeHEg9P84nS8g8UkM82j2u8xJJ7cVLU8Q Idp1d7b4d1oj4zUf5SGIUB4d/3u4hA7/Vx8cMX5acpabLqCbUNbZVvd4ApmLdlrzUToU ilAMZRG3TX5sbVyT7PmcGTYix1oeh6+AZ0NttzEx4yhF2KP2YngoLoWncUxVbGEWCFUz fAIg== 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=9WLuBTRuBUsHt7celv30OZ0xH9Zz2VNAqw+Rg6atRTA=; b=DNrJCpj0uEMebuPQagek2q2LhZpDCRq+IIje7ALXScWOskZqwJQi22a1mTF2FBeoZE H0P+4BsRnHg3CFD96zpGM7QjdWeFzGqRddPlTeNvy7b9WyFeMBEtHo9Yz8DWwEocqp2M dmPi7bGEJq7Y3Oeia1YPdzp1WQbMRhnRF+ZhplAvKbbt3lVT114QidTGEaAc9Td7RFv2 6VTbuyunlN+alRGewQq+kIl/9xgngdi+uL8NKjayzcWe/W/ZFtqY5qMxkhJHFUsjsvKM x7A0oYdgdS0PmDm6Z/rx+xDrQ1N3UYgS5GvfKjgE8jUQWsccpm1OH9FlC57eWiAvllw5 OGkA== X-Received: by 10.66.217.195 with SMTP id pa3mr44639444pac.120.1373650357484; Fri, 12 Jul 2013 10:32:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Fri, 12 Jul 2013 10:31:57 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30D110@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30D110@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Fri, 12 Jul 2013 10:31:57 -0700 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=047d7b5d438c9a998404e153e5d7 X-Gm-Message-State: ALoCoQmHjji9ij5ts7riDnVE0RdMN9jCvdOmnS33RXDkF631kpjaYPdIHIKz9q8oNey0pJcyk+Sso4YfFfsXHU4KxhtA+xaP+2Zn9Je/QEUgyRpESk1pQraxBuWyxymxdidt3lFsI3AjZMW1rqjmDSbVMPbKJrONJJmXVsyjjWkzJloijV45NXqZyMlNKVtF2S+xKcZ5coY7 Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:32:38 -0000 --047d7b5d438c9a998404e153e5d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 9, 2013 at 4:26 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 2013-07-09 12:18, I=C3=B1aki Baz Castillo wrote: > > 2013/7/9 Stefan H=C3=A5kansson LK : > >> I want to be very clear and careful on what I say. So I am repeating: > >> > >> * My comment that I think Eric is right in that there is consensus on > >> providing APIs that allow most use-cases to be met without SDP manglin= g > >> is meant only in that context: SDP O/A is kept (and PeerConnection mor= e > >> or less as is and so on). > > > > Hi Stefan, > > > > You insist that "there is consensus on keeping SDP O/A but providing a > > better API". > > I must be expressing myself quite badly, because the message seems not > to get through. > > * I think we have consensus on adding API that allows most use-cases to > be met without SDP mangling (given that SDP O/A is kept naturally) > > * We discussed last year an alternative API that did not use SDP at all > (and did not use PeerConnection). The decision at that time was to > continue developing the API based on PeerConnection and SDP O/A. > > Have not stated anything more than that. > Thank you for clarifying, Stefan. It's often very difficult for those of us who weren't there to understand what was consensus, and what wasn't, and what was decided and what was decided and what wasn't. It seems that if you ask 10 people, you get 10 different answers. In other words, it's hard to see much consensus on what we have consensus on. So thank you for your clarifications. It's probably not a very fun job for you :). Along with that, I have two more questions for you: 1. You said we have consensus on adding API that allows most use-cases to be met without SDP mangling. Since that point in time has there been in any progress in adding such APIs? Can you give me a rough feel for how much time has passed, how many proposals have been made, how many have been accepted, and how many have been implemented? I think it's great that we'll do this "someday", but I'd like to get a feel for how far away "someday" is. Thanks in advance. 2. You said we have consensus against an alternative API. Was that consensus against any additions to the API that would allow JS to bypass SDP, or was that a consensus against just that particular alternative API? I'd like to get a feel for how many people voted for "no; let's not go down that specific road" vs. "no; we cannot go on any road but this one". I think there's a big difference between the two. Thanks again in advance. By the way, Ted asked us to move discussions about the API to public-webrtc, so should we do that now? > Stefan > > > Given current discussions IMHO it is clear there is not > > such a consensus (not at all). Or may be you are just talking about > > two years ago in some IETF meeting (if so I'm sorry). > > > > Please review the results in > > > https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdH= lZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1 > > > > Bad for advanced stuff: 94% > > OK for 1.0: 40% > > > > IMHO such a result indicates all but "let's keep SDP O/A and improve a > > bit the API" (I mean now, in July 2013). > > > > > > Best regards. > > > > > > > > -- > > I=C3=B1aki Baz Castillo > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b5d438c9a998404e153e5d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 9, 2013 at 4:26 AM, Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
On 2013-07-09 12:18, I=C3=B1aki Baz Cast= illo wrote:
> 2013/7/9 Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com>:
>> I want to be very clear and careful on what I say. So I am repeati= ng:
>>
>> * My comment that I think Eric is right in that there is consensus= on
>> providing APIs that allow most use-cases to be met without SDP man= gling
>> is meant only in that context: SDP O/A is kept (and PeerConnection= more
>> or less as is and so on).
>
> Hi Stefan,
>
> You insist that "there is consensus on keeping SDP O/A but provid= ing a
> better API".

I must be expressing myself quite badly, because the message seems no= t
to get through.

* I think we have consensus on adding API that allows most use-cases to
be met without SDP mangling (given that SDP O/A is kept naturally)

* We discussed last year an alternative API that did not use SDP at all
(and did not use PeerConnection). The decision at that time was to
continue developing the API based on PeerConnection and SDP O/A.

Have not stated anything more than that.

Thank you for clarifying, Stefan. =C2=A0It's often very difficult for= those of us who weren't there to understand what was consensus, and wh= at wasn't, and what was decided and what was decided and what wasn'= t. =C2=A0It seems that if you ask 10 people, you get 10 different answers. = =C2=A0


In other words, it's hard to see muc= h consensus on what we have consensus on.


So thank you for your clarifications. =C2=A0It's probably not a = very fun job for you :). =C2=A0 Along with that, I have two more questions = for you:


1. =C2=A0You said we have consensus on a= dding API that allows most use-cases to be met without SDP mangling. =C2=A0= Since that point in time has there been in any progress in adding such APIs= ? =C2=A0Can you give me a rough feel for how much time has passed, how many= proposals have been made, how many have been accepted, and how many have b= een implemented? =C2=A0I think it's great that we'll do this "= someday", but I'd like to get a feel for how far away "someda= y" is. =C2=A0Thanks in advance.

2. =C2=A0You said we have consensus against an alternat= ive API. =C2=A0Was that consensus against any additions to the API that wou= ld allow JS to bypass SDP, or was that a consensus against just that partic= ular alternative API? =C2=A0I'd like to get a feel for how many people = voted for "no; let's not go down that specific road" vs. &quo= t;no; we cannot go on any road but this one". =C2=A0 I think there'= ;s a big difference between the two. =C2=A0Thanks again in advance.


By the way, Ted asked us to move discuss= ions about the API to public-webrtc, so should we do that now?


Stefan

> Given current discussions IMHO it is clear there is not
> such a consensus (not at all). Or may be you are just talking about > two years ago in some IETF meeting (if so I'm sorry).
>
> Please review the results in
> http= s://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdHlZdV9R= N0xSWFhybVl4anJLRkVPV0E#gid=3D1
>
> =C2=A0 =C2=A0Bad for advanced stuff: 94%
> =C2=A0 =C2=A0OK for 1.0: 40%
>
> IMHO such a result indicates all but "let's keep SDP O/A and = improve a
> bit the API" (I mean now, in July 2013).
>
>
> Best regards.
>
>
>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
>

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

--047d7b5d438c9a998404e153e5d7-- From martin.thomson@gmail.com Fri Jul 12 10:41:45 2013 Return-Path: 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 58F4021F9928 for ; Fri, 12 Jul 2013 10:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, 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 2RJ-mdNLF-tx for ; Fri, 12 Jul 2013 10:41:44 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 07DFD21F9A38 for ; Fri, 12 Jul 2013 10:41:17 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so8437391wes.31 for ; Fri, 12 Jul 2013 10:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=T//EXiGfXfaPZh46cuEkVJlN3UqhjRAxPeKjEmSuGUc=; b=qlNAAe5+8kni6OMYkEsm3mEBX8UR1XCna8ci/M1g/EiGBjKYjYWQ4cKOSmaneYQqNg SxfnHLvgc6Sbbft6Y2eaIdIbojAQNmDAV9033qhNIeS8ZEah7I3FDFX1IHZSIa+S7dd3 4ePXTY9H/QSutZq4kVjsg30LslvorZltYYJ8IknMSS3al74DClBmX4k1Pd/1F3lVUqPh HaVQvnZwVGSWLQ6R3XUHwVHT+rQolxnb+rfG+mL66Z9PcLbQYncGSK9qf/Mzl5D7OEWk rritDujHPU9vQhyjPHdBbrJ1ANgs9xyCbXbMB8+JBlMLByLtqaUECFnoMQXY2d0p/4We cxeQ== MIME-Version: 1.0 X-Received: by 10.180.73.68 with SMTP id j4mr2331325wiv.10.1373650877184; Fri, 12 Jul 2013 10:41:17 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 12 Jul 2013 10:41:17 -0700 (PDT) Date: Fri, 12 Jul 2013 10:41:17 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "" Subject: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:41:45 -0000 On 12 July 2013 10:19, Peter Thatcher wrote: > I think advanced JS apps are going to use every control knob they can get > to, whether it's anticipated and well-supported or not. I think there's a > good chance that a a popular WebRTC web app will use some SDP mangling that > wasn't anticipated, but happened to work, but then the browser can't remove > it because it will break certain websites. It could get even worse if > someone writes a popular WebRTC wrapper library that uses tricky SDP > mangling that is then used by lots of websites. Certain SDP mangling > techniques might end up becoming a defacto standard API that can't be > removed, even if it was originally a bug. Or worse, one browser will have > to implement the SDP mangling or even the bugs of another, because WebRTC > apps have come to rely on them. > > In fact, it's already the case that Chrome and Firefox support far different > SDP manglings. I don't think any web apps rely on that yet, but it's only a > matter of time before someone figures out "hey, if I mangle the SDP on this > browser this way and on that browser that way, I can do things I couldn't do > otherwise". Or worse, an advanced web app developer says "hey, I can make > this work well on browser X via SDP mangling, but not on browser Y, so I'll > put a 'best used with Browser X' icon on my website". Then that someone > writes an abstraction on top of that, and then maybe shares that with > others, and it goes from there. > > I think we're in a race with web developers to see if they'll figure out SDP > mangling before we provide a way to avoid SDP mangling. Who do you think > moves faster? This is one of the arguments we've made against the use of SDP. There is a remedy for this (aside from comment 22 ;), but it's a fair amount of work: - provide very explicit and detailed instructions on what SDP to produce under all starting conditions, and - provide very explicit and detailed instructions on what to do with every single bit of SDP that is provided. That is what I believe to be necessary if this API is to have any hope of real success. Unfortunately, when I sat down to do this, I barely made it to t= sections. I simply cannot justify spending the time required for that sort of chore. From fluffy@cisco.com Fri Jul 12 10:42:45 2013 Return-Path: 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 EF3F921E80AE for ; Fri, 12 Jul 2013 10:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 aQLJ4ScCBwOE for ; Fri, 12 Jul 2013 10:42:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 68FD421E80AD for ; Fri, 12 Jul 2013 10:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=353; q=dns/txt; s=iport; t=1373650960; x=1374860560; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y8Ujir/m2GLb8Vjj2Vlg2O25ZUQFbd6Aogs3Lo4IByk=; b=RQRcQ2qvSuLAjN0pBZSaBf+DATeAtvkxx22vcabe9VCvAMVYHxObvq8i t/eODKy6vyb6CmvNmGcKKl3LjgOh6koCzHMMK95IH7tbT7bL5xDl8D29L e3uEtvOlEZpg3xd+VQPz5VvdulujcAi0qlmtagsfsLa7ywusTT4JTUH5y s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAH4/4FGtJV2d/2dsb2JhbABagwaBA4I/vxKBDBZ0giMBAQEDAXkFCwIBCCIkIRElAgQOBQiHdQMJBq8aDYhejHiCNgIxB4MLbAOIb40EjhCFJoMSgig X-IronPort-AV: E=Sophos;i="4.89,654,1367971200"; d="scan'208";a="234154239" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 12 Jul 2013 17:42:40 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6CHgdHN019811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 17:42:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 12:42:39 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: division of responsibilities (was: Draft agenda for IETF 87) Thread-Index: AQHOfxmZKPbXE869BEKXiSv5F7Mwd5lhpAaA Date: Fri, 12 Jul 2013 17:42:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.236] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5A8DDED43A4F394DA268B1F5BFF90F81@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] division of responsibilities (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:42:46 -0000 On Jul 12, 2013, at 9:04 AM, Martin Thomson wrote: > With all respect > to the chairs, that's not something I trust them to rule on at this > point. just to be clear, I don't think the RTCWeb chairs have done anything remote= ly close to a ruling on this. We have taken censuses calls on the use of 32= 64 O/A. From martin.thomson@gmail.com Fri Jul 12 10:54:25 2013 Return-Path: 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 6E51921E80B4 for ; Fri, 12 Jul 2013 10:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, 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 4XJIz6pCMQz3 for ; Fri, 12 Jul 2013 10:54:25 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id C3B8B21E80AD for ; Fri, 12 Jul 2013 10:54:24 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so8303919wev.36 for ; Fri, 12 Jul 2013 10:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JEDbew8jz8nAjXJxOLNBIbTGWlqDyX1W0psVVt8TR4M=; b=IY46eytJLezk3TOB+bv2hnaBOvcWkVk/dBNudYxn/kxAMtG2bmOVJ9q32E4SkhTon5 qBKnho6TJnxGn9+nZw9m06DrWTG4GwTIbsrZodXQbLHHHNIznAeYGPu49/jnSLRNmlaY axzVhToTIRF9088JsPM1e1wgktw7buRCtueVCJCxhTrpZSnh94dQ5uQpq0HJbVgsyP+2 Uq1DU5acucxfhbo7LqO0ZB2znvRZZPVwmhj3jCNalZQ+yIprVhkB64FuCe1jimH//7Ma yEAvg6dg9jzwiOw9T63bXuZD/IvhqwzfvJVpMqTSSC0d0z5oVwBTDRbAFm9VEJzjHcCV HAHg== MIME-Version: 1.0 X-Received: by 10.180.83.163 with SMTP id r3mr2352980wiy.10.1373651663950; Fri, 12 Jul 2013 10:54:23 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 12 Jul 2013 10:54:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jul 2013 10:54:23 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [rtcweb] division of responsibilities (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:54:25 -0000 On 12 July 2013 10:42, Cullen Jennings (fluffy) wrote: > On Jul 12, 2013, at 9:04 AM, Martin Thomson > wrote: >> With all respect >> to the chairs, that's not something I trust them to rule on at this >> point. > > just to be clear, I don't think the RTCWeb chairs have done anything remotely close to a ruling on this. We have taken censuses calls on the use of 3264 O/A. I didn't mean to imply that a ruling has been made. To a large extent, we haven't even discussed the issue that no-plan represents. That's a large part of where my concern derives from. It's a tricky situation: chairs have to make rulings on the appropriate venue for discussion, but when that ruling seems to be predicated on having a technical decision, it creates a bind. From pthatcher@google.com Fri Jul 12 11:22:05 2013 Return-Path: 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 91A0521E80A9 for ; Fri, 12 Jul 2013 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.045, 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 4wNjLAr+ICjw for ; Fri, 12 Jul 2013 11:22:04 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9D95221E80A5 for ; Fri, 12 Jul 2013 11:22:02 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so9262820pbc.3 for ; Fri, 12 Jul 2013 11:22:02 -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=FvsIv7D5axYJSWQ5uD9AR/jNrfZPbLet7tPmseqo+p0=; b=XsKnEPMzKJeI5L90qNdn2QfdzwljCbuk7v7K+HEfapzBnZUZJh6ch6KVvfSP8pc+vM k93WGF1WRrJMDB3riV2qZXgir0GVoCT1L7xRQ7QBbW/teC77fhAevANixuF4xdJvAMaG NVeYtPSYQH4LFpX5I7fn5Aw5sQZNjidtpMjSIX2ca7UH/WXgnnxjoa4gL0ixGBPpMPTK HM8YfVG6QO1XjPbM44bjuShgzSC30ZJPwr6y5iAXZJqIUVJX0zYwnR8Ito3wTwyx5xtI mqUZTYnzr49Ar7Q3/kUNs6xYZP7hUmBGK2cMv/DPCXCqW2mUrOZmUNc39f6VP4C3Y/+0 Ip8w== 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=FvsIv7D5axYJSWQ5uD9AR/jNrfZPbLet7tPmseqo+p0=; b=EfVFbIDYrNCp1zMgZxpi6DPV6EQTR3HJWXeWRebgK5xTjDefDJqGgDnvGDEBnRfITG o+Yr21I2OZqP8R7mMGK1nqvAJxBHvr5j0LYR1ZvVjAdMKH5v6AIgNTnIl6a0zVZ3ABME xNL9pcYEexQvcpHyXAlTAj+n173y27uqkNtnaBiJIPbSIJ/BdmL4WFKRyKqJCOvtjMCG fooWLM93oMKWIiQHXR+EzhFjr6KDfL+bxgGfPWqa0wiuM264YmC3Rl2lnQ8yY73bnJpW tE0+I7HSMF5mpYolX9zxJjWI4BQmbnoQUIlm6HtUHGUWb6VlMTUnQ8CqNcIFEHkvx8LW MRqg== X-Received: by 10.66.14.196 with SMTP id r4mr45103234pac.57.1373653322110; Fri, 12 Jul 2013 11:22:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Fri, 12 Jul 2013 11:21:21 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Fri, 12 Jul 2013 11:21:21 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=bcaec51f99e54f49c504e15496f0 X-Gm-Message-State: ALoCoQl/oNYoGOwuFjfizsAxF3IinVdbVmu+WA5VNjrIPokw+BpoVVFaBAB8N166/Zs9o7I2or7Cikj3OGxbXqH+FYLAbq6CyxcV4vAVUJTLqgkPtnsX5AZfob3gSJyKWPK41OIPPZtU37dil0KNy6NMDOQTGxy5j0TfSeaUjEqHGbPVjekNdL1GL7nZNGdaaDjuf43j/8gC Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 18:22:05 -0000 --bcaec51f99e54f49c504e15496f0 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 12, 2013 at 10:41 AM, Martin Thomson wrote: > On 12 July 2013 10:19, Peter Thatcher wrote: > > I think advanced JS apps are going to use every control knob they can get > > to, whether it's anticipated and well-supported or not. I think > there's a > > good chance that a a popular WebRTC web app will use some SDP mangling > that > > wasn't anticipated, but happened to work, but then the browser can't > remove > > it because it will break certain websites. It could get even worse if > > someone writes a popular WebRTC wrapper library that uses tricky SDP > > mangling that is then used by lots of websites. Certain SDP mangling > > techniques might end up becoming a defacto standard API that can't be > > removed, even if it was originally a bug. Or worse, one browser will > have > > to implement the SDP mangling or even the bugs of another, because WebRTC > > apps have come to rely on them. > > > > In fact, it's already the case that Chrome and Firefox support far > different > > SDP manglings. I don't think any web apps rely on that yet, but it's > only a > > matter of time before someone figures out "hey, if I mangle the SDP on > this > > browser this way and on that browser that way, I can do things I > couldn't do > > otherwise". Or worse, an advanced web app developer says "hey, I can > make > > this work well on browser X via SDP mangling, but not on browser Y, so > I'll > > put a 'best used with Browser X' icon on my website". Then that someone > > writes an abstraction on top of that, and then maybe shares that with > > others, and it goes from there. > > > > I think we're in a race with web developers to see if they'll figure out > SDP > > mangling before we provide a way to avoid SDP mangling. Who do you > think > > moves faster? > > This is one of the arguments we've made against the use of SDP. There > is a remedy for this (aside from comment 22 ;), but it's a fair amount > of work: > > - provide very explicit and detailed instructions on what SDP to > produce under all starting conditions, and > > - provide very explicit and detailed instructions on what to do with > every single bit of SDP that is provided. > If we write it down with such detailed instructions, is a browser banned from accepting more than the explicitly allowed SDP in calls to setLocalDescription and setRemoteDescription? For example, what if lots of web apps get SDP from a particularly popular gateway device that adds a particular SDP attribute, and if the browser "listens" to that SDP attribute, things work better (for example, it might be a bandwidth-related attribute). Can the browser "listen" to that SDP attribute even though it isn't explicitly supported by the WG? Or does it have to wait for it to be added to the explicit instructions? > That is what I believe to be necessary if this API is to have any hope > of real success. > > It depends on how you define "real success". I think the API has already had success for simple use cases, seeing as two browsers have working, interoperable implementations for the simple use cases. It's the advanced ones I see being problematic. > Unfortunately, when I sat down to do this, I barely made it to t= > sections. I simply cannot justify spending the time required for that > sort of chore. > Well, then you're almost finished. All you really have left are the m= sections :). --bcaec51f99e54f49c504e15496f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 12, 2013 at 10:41 AM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 12 July 2013 10:19, Peter Thatcher <pthatcher@google.co= m> wrote:
> I think advanced JS apps are going to use every control knob they can = get
> to, whether it's anticipated and well-supported or not. =C2=A0 =C2= =A0I think there's a
> good chance that a a popular WebRTC web app will use some SDP mangling= that
> wasn't anticipated, but happened to work, but then the browser can= 't remove
> it because it will break certain websites. =C2=A0It could get even wor= se if
> someone writes a popular WebRTC wrapper library that uses tricky SDP > mangling that is then used by lots of websites. =C2=A0Certain SDP mang= ling
> techniques might end up becoming a defacto standard API that can't= be
> removed, even if it was originally a bug. =C2=A0Or worse, one browser = will have
> to implement the SDP mangling or even the bugs of another, because Web= RTC
> apps have come to rely on them.
>
> In fact, it's already the case that Chrome and Firefox support far= different
> SDP manglings. =C2=A0I don't think any web apps rely on that yet, = but it's only a
> matter of time before someone figures out "hey, if I mangle the S= DP on this
> browser this way and on that browser that way, I can do things I could= n't do
> otherwise". =C2=A0Or worse, an advanced web app developer says &q= uot;hey, I can make
> this work well on browser X via SDP mangling, but not on browser Y, so= I'll
> put a 'best used with Browser X' icon on my website". The= n that someone
> writes an abstraction on top of that, and then maybe shares that with<= br> > others, and it goes from there.
>
> I think we're in a race with web developers to see if they'll = figure out SDP
> mangling before we provide a way to avoid SDP mangling. =C2=A0 Who do = you think
> moves faster?

This is one of the arguments we've made against the use of SDP. =C2=A0T= here
is a remedy for this (aside from comment 22 ;), but it's a fair amount<= br> of work:

=C2=A0- provide very explicit and detailed instructions on what SDP to
produce under all starting conditions, and

=C2=A0- provide very explicit and detailed instructions on what to do with<= br> every single bit of SDP that is provided.

If we write it down with such detailed instructions, is a browser banned= from accepting more than the explicitly allowed SDP in calls to setLocalDe= scription and setRemoteDescription? =C2=A0For example, what if lots of web = apps get SDP from a particularly popular gateway device that adds a particu= lar SDP attribute, and if the browser "listens" to that SDP attri= bute, things work better (for example, it might be a bandwidth-related attr= ibute). =C2=A0Can the browser "listen" to that SDP attribute even= though it isn't explicitly supported by the WG? =C2=A0Or does it have = to wait for it to be added to the explicit instructions?



That is what I believe to be necessary if this API is to have any hope
of real success.


It depends on how you define "rea= l success". =C2=A0 I think the API has already had success for simple = use cases, seeing as two browsers have working, interoperable implementatio= ns for the simple use cases. =C2=A0It's the advanced ones I see being p= roblematic.



=C2=A0
Unfortunately, when I sat down to do this, I barely made it to t=3D
sections. =C2=A0I simply cannot justify spending the time required for that=
sort of chore.

Well, then you're al= most finished. =C2=A0All you really have left are the m=3D sections :).

--bcaec51f99e54f49c504e15496f0-- From emcho@sip-communicator.org Fri Jul 12 11:28:29 2013 Return-Path: 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 8475E21F9F5E for ; Fri, 12 Jul 2013 11:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Y66XSHd0Vagi for ; Fri, 12 Jul 2013 11:28:25 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 78AE321F9F47 for ; Fri, 12 Jul 2013 11:28:21 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so8266282wes.41 for ; Fri, 12 Jul 2013 11:28:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=9Ueypkf8TDhbmXULsElaf4BJCkDvdHIA/dDJqyEiol4=; b=C9GlKxwTUkE+I9yXq+NulDFISBCk5kBa6YIBFgH7Z1r1a4TN5mBhFaejiubVHjl3UT B0JdB34O41rYQwqfQC5qkuGuVwc8fTaxpk7NQeTmwltEDgk0AlKTkkDC8EhRqBcCzYjs sIeaoXgSPhNlfAJz+GpuDwieDBOl/7t3tJFCdgkLggUW68z/5XE7wRZmDBOvyeZhv9TI +eEubgng3nmLOB6Y/zX7yibJq5kn/YFJAs87jZq4AxuRWEUGhmU73Fora2PNh12bBqsR SOBbS9tvmcN9zLblN1JbhoD44m0RxARUu1M7TRoC6LyAoN+aw4K/t+28jns99UQL8CFU SCxg== X-Received: by 10.194.179.129 with SMTP id dg1mr25532583wjc.38.1373653700215; Fri, 12 Jul 2013 11:28:20 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [2607:f8b0:400c:c01::235]) by mx.google.com with ESMTPSA id h8sm4959304wie.1.2013.07.12.11.28.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 11:28:19 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db10so8534273veb.12 for ; Fri, 12 Jul 2013 11:28:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.235.69 with SMTP id uk5mr24827881vec.17.1373653698075; Fri, 12 Jul 2013 11:28:18 -0700 (PDT) Received: by 10.221.45.71 with HTTP; Fri, 12 Jul 2013 11:28:18 -0700 (PDT) Received: by 10.221.45.71 with HTTP; Fri, 12 Jul 2013 11:28:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jul 2013 20:28:18 +0200 Message-ID: From: Emil Ivov To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7bd6c2c4b7f75e04e154acf0 X-Gm-Message-State: ALoCoQn2PTqsucCIG2I2EVi/Prj1KsyduVnm5NbK3KmeT3E0PUlAlGcFEixmSUEqI7G22SmQwwV4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] division of responsibilities (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 18:28:29 -0000 --047d7bd6c2c4b7f75e04e154acf0 Content-Type: text/plain; charset=ISO-8859-1 Just to be clear: use of SDP O/A is precisely the intended topic of the slot we are requesting. --sent from my mobile On Jul 12, 2013 7:42 PM, "Cullen Jennings (fluffy)" wrote: > > On Jul 12, 2013, at 9:04 AM, Martin Thomson > wrote: > > > With all respect > > to the chairs, that's not something I trust them to rule on at this > > point. > > just to be clear, I don't think the RTCWeb chairs have done anything > remotely close to a ruling on this. We have taken censuses calls on the use > of 3264 O/A. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bd6c2c4b7f75e04e154acf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Just to be clear: use of SDP O/A is precisely the intended t= opic of the slot we are requesting.

--sent from my mobile

On Jul 12, 2013 7:42 PM, "Cullen Jennings (= fluffy)" <fluffy@cisco.com&= gt; wrote:

On Jul 12, 2013, at 9:04 AM, Martin Thomson <martin.thomson@gmail.com>
=A0wrote:

> With all respect
> to the chairs, that's not something I trust them to rule on at thi= s
> point.

just to be clear, I don't think the RTCWeb chairs have done anything re= motely close to a ruling on this. We have taken censuses calls on the use o= f 3264 O/A.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--047d7bd6c2c4b7f75e04e154acf0-- From martin.thomson@gmail.com Fri Jul 12 11:29:12 2013 Return-Path: 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 E41DD21F9F6B for ; Fri, 12 Jul 2013 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, 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 p2mTtMVHKzd0 for ; Fri, 12 Jul 2013 11:29:12 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 31DC721F9F72 for ; Fri, 12 Jul 2013 11:28:42 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so8291128wgh.11 for ; Fri, 12 Jul 2013 11:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SEnNJb0S6Dy/X3x+83FEDTkFfns61x46ZX4m76I3vMI=; b=o81HExJ0pPboUJuSpMQKCNLpsEUY5oQG6JGRgbgKUqIhQpvOY1GvRgiZK7r+tRq22F 1ujGCId/zDJNM1/Qr8Aq6M0Adsj3RHR6NVzkfH2ViF/2OHL4SThBq0wKd4HcdWt7xd20 yqJ9CgH7b06iLDpISbXsI9pxHpNYqBwqI9vwpyMcpGp+ZFvw9YCDTYUtOPUeKMLNJnYm 6yNrMbqBakqytEJYig4EItwBbv5MtTH3mvnyUHuk7xdBTKjQKeuG2PynrtzZoJd4+ot3 dhALT8TNxL9ji+AN9pJfy443mqPkkuLjJGXT423JQOcmThpBqBt9Sw0pzzY3EgMiS/O/ Yevw== MIME-Version: 1.0 X-Received: by 10.194.110.6 with SMTP id hw6mr25253776wjb.3.1373653721281; Fri, 12 Jul 2013 11:28:41 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 12 Jul 2013 11:28:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jul 2013 11:28:41 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 18:29:13 -0000 On 12 July 2013 11:21, Peter Thatcher wrote: > If we write it down with such detailed instructions, is a browser banned > from accepting more than the explicitly allowed SDP in calls to > setLocalDescription and setRemoteDescription? For example, what if lots of > web apps get SDP from a particularly popular gateway device that adds a > particular SDP attribute, and if the browser "listens" to that SDP > attribute, things work better (for example, it might be a bandwidth-related > attribute). Can the browser "listen" to that SDP attribute even though it > isn't explicitly supported by the WG? Or does it have to wait for it to be > added to the explicit instructions? That depends entirely on the nature of the instructions. Allowing for extensibility is always really, really hard, but maybe there is enough experience with SDP now that this sort of scenario could be supported. From ibc@aliax.net Fri Jul 12 11:30:41 2013 Return-Path: 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 7462321F9F6B for ; Fri, 12 Jul 2013 11:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 kEiXApA991Nq for ; Fri, 12 Jul 2013 11:30:36 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 46A9C21F9F3D for ; Fri, 12 Jul 2013 11:30:35 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so506651qab.7 for ; Fri, 12 Jul 2013 11:30:35 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=OizIFR1Nm7xFSeky5kv/Vh3rPB26rE35vQjXAvWvfn0=; b=kjfnmpYnNwa7VYe1dZG9cHvWUVntMwRRZarK0dYC9ehR813fn8CsMsCILqBiQwKqvt rNrSJXTbP4JaC9bSd6jBN7CTzHEt3Kj0ySMp+v5Q47wecTvUgn9wXHy5L//ev9sL2V0q rZji6dCxir3LeyGt7WtL/3uL11NY8kSo5GDFGGnNQ1vrVk49TMtbnykRKNclx1U4Q7by Rkr+USkGZObzrx3xjdd9Ed0ic4uZ+dkrf3ga54TvnSd61ufZ7AiTduBp0LZ4so1zYrIw fi/VSop4N8STmI7ES9etOyb29tHbiWGih/5IuipS0Ck5FUXzHGvur+uVFih7lG/wSWV8 LtNA== X-Received: by 10.224.182.79 with SMTP id cb15mr39330439qab.48.1373653835406; Fri, 12 Jul 2013 11:30:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Fri, 12 Jul 2013 11:30:15 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 12 Jul 2013 20:30:15 +0200 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkho8YJVp8XMRYb5lIetgxwz4oXIlISwWI/oe3L71ozzaQa2DdR/qIh3e6WB8PXhaSQPuMX Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] division of responsibilities (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 18:30:41 -0000 2013/7/12 Emil Ivov : > Just to be clear: use of SDP O/A is precisely the intended topic of the s= lot > we are requesting. Do you mean "use or non-use of SDP O/A"? -- I=C3=B1aki Baz Castillo From pthatcher@google.com Fri Jul 12 12:01:37 2013 Return-Path: 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 5148321F9CA2 for ; Fri, 12 Jul 2013 12:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_URI_CONS7=0.306] 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 iIrN8YtjtkYu for ; Fri, 12 Jul 2013 12:01:36 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9E36B21F9E58 for ; Fri, 12 Jul 2013 12:01:12 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un1so9373050pbc.1 for ; Fri, 12 Jul 2013 12:01:12 -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=APudZcQi2N5ZkpCbvvjAPaq6Aivg98sSvep2E+jlCUk=; b=IChEhcc5CSFPtyFfyPuj3NMIMUZiUxiSD35GhJJ2gAVt0VXVXcAOuXwgArslKR3qMa XIlVZy9NMJbhlvo7oDHYBm159Wr7p3gftrI54JGjx48azdzV4f2WZfQprNOl4o0140OY jISEbhNiHwqkTl/0TcqAU3oyVZXi22tZ2AZ0LmkyxmQEKB/ehf/sCub9VJWKDYg9Q8a7 NrFEYkXUD5RYvJOw9ZAJ0SNMT4PxGZuzj/878GH79LO+o38UrDFnajdHL+jNIw2sq1hU U4V5Kc4yurz52wNSkh/UVduSNprXiFCkkPX/YZ7jkV4j+bMNhMsuMvoOwvPT1AqdkYli dveA== 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=APudZcQi2N5ZkpCbvvjAPaq6Aivg98sSvep2E+jlCUk=; b=YGf0UW9AVLYwCnZWkFZH84FUk8cZsizb0JuvAgfViizwEbVIdbpqP4NAsTxblRpILI nOppHwAYaVh4QWcs/gzOmOEU9EcJvt/S4tgH8/WHBX43pxcZeetcbCN3sqUIcgQalHud 1v8hbE9ISwgHhTi1uGRUPj99eVKcjvuABkuy0n6jwImQ6yiBBxmEGXWrQUtdI3Ka7Znh nutcfmX2W0LYrZYSMLx+kQSqv9eIsU+I5GeJOit2uFeV4H3L6S3mxYoXHOiOiJ0/mT5Y +RYsYaxm82P6eATBBFs5O4RCUN6pXScM9T6cE4JV3cNtBlRiIYkFuU3lBQjNY8OOoeP/ Ds4Q== X-Received: by 10.66.243.5 with SMTP id wu5mr39503754pac.44.1373655672330; Fri, 12 Jul 2013 12:01:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Fri, 12 Jul 2013 12:00:32 -0700 (PDT) In-Reply-To: References: <51CA6FEE.6030702@hookflash.com> From: Peter Thatcher Date: Fri, 12 Jul 2013 12:00:32 -0700 Message-ID: To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=047d7b111f5f64ab3104e15522fe X-Gm-Message-State: ALoCoQnEfSTRCd+rP2rIU3RG85tsIitUpqCu3pR7zsaNYa0o61etIvHEnpAGoqQN0RdPZ8j4SUmuH5w0RJWbV/MwfjyuPU/ljeqOYHGdsRGE6+AgJVtqg2H2shVwwD61xgr37ChWxUdvJ6qLYBoKbG/hTk0PdOHW5Ts90GNWa3V8MDA9+rvoYwEsv5rjf57UKgpPLPH7rYIU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 19:01:38 -0000 --047d7b111f5f64ab3104e15522fe Content-Type: text/plain; charset=UTF-8 I wasn't aware of that. Thanks for letting me know. On Mon, Jul 8, 2013 at 9:02 AM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > Some of us work for browser vendors who cannot follow that link, you > know.**** > > ** ** > > Matthew Kaufman**** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Peter Thatcher > *Sent:* Monday, July 8, 2013 8:01 AM > *To:* Silvia Pfeiffer > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] New Draft - WebRTC JS Object API Model**** > > ** ** > > ** ** > > ** ** > > On Sat, Jul 6, 2013 at 3:59 AM, Silvia Pfeiffer > wrote:**** > > An interesting read. It makes me wonder if there is a full description > available of the SDP that browsers (Chrome, Firefox) currently > support.**** > > ** ** > > Here's the description for Chrome:**** > > ** ** > > > https://code.google.com/p/libjingle/source/browse/trunk/talk/app/webrtc/webrtcsdp.cc > **** > > ** ** > > :)**** > > **** > > > Looking forward to your proposal (I assume it will be on the W3C list?). > > Cheers, > Silvia.**** > > > On Wed, Jun 26, 2013 at 2:37 PM, Robin Raymond > wrote: > > > > According to many, real adoption of WebRTC will not happen if we > continue to > > force everyone to use this SDP Offer/Answer methodology. It is clearly > > blocking our way forward and the amount of specification documentation > > remaining needed for the browser vendors to produce a compatible SDP > based > > WebRTC engine in a browser is much more daunting than most are willing to > > admit. > > > > > > The draft rationale behind a JavaScript Object API model: > > > > > http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt > > > > Whereas: > > > > The WebRTC JavaScript Object API & Shim document will be along shortly. > > > > > > We wanted to get this initial rationale draft informational document out > > right away. Everyone that has any interest should review the reasons and > > concepts and comment before we get too far along on the details of an > actual > > API, the initial API will follow in the coming days. > > > > > > Best regards, > > > > Robin Raymond > > > >**** > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb**** > > ** ** > --047d7b111f5f64ab3104e15522fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wasn't aware of that. =C2=A0Thanks for letting me kn= ow.


On Mon= , Jul 8, 2013 at 9:02 AM, Matthew Kaufman (SKYPE) <matthew.kaufman= @skype.net> wrote:

Some of us work for browser vendors who cannot follow t= hat link, you know.

=C2=A0

Matthew Kaufman=

=C2=A0

From: rtcweb-bounces@ietf.= org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Peter Thatcher
Sent: Monday, July 8, 2013 8:01 AM
To: Silvia Pfeiffer
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model<= u>

=C2=A0

=C2=A0

=C2=A0<= /p>

On Sat, Jul 6, 2013 at 3:59 AM, Silvia Pfeiffer <= silviapfeiff= er1@gmail.com> wrote:

An interesting read. It makes me wonder if there is = a full description
available of the SDP that browsers (Chrome, Firefox) currently
support.

=C2=A0

Here's the description for Chrome:=

=C2=A0

=C2=A0

:)

=C2=A0


Looking forward to your proposal (I assume it will be on the W3C list?).
Cheers,
Silvia.


On Wed, Jun 26, 2013 at 2:37 PM, Robin Raymond <robin@hookflash.com> wrote:
>
> According to many, real adoption of WebRTC will not happen if we conti= nue to
> force everyone to use this SDP Offer/Answer methodology. =C2=A0It is c= learly
> blocking our way forward and the amount of specification documentation=
> remaining needed for the browser vendors to produce a compatible SDP b= ased
> WebRTC engine in a browser is much more daunting than most are willing= to
> admit.
>
>
> The draft rationale behind a JavaScript Object API model:
>
> http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api-= rationale-00.txt
>
> Whereas:
>
> The WebRTC JavaScript Object API & Shim document will be along sho= rtly.
>
>
> We wanted to get this initial rationale draft informational document o= ut
> right away. Everyone that has any interest should review the reasons a= nd
> concepts and comment before we get too far along on the details of an = actual
> API, the initial API will follow in the coming days.
>
>
> Best regards,
>
> Robin Raymond
>
>

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

=C2=A0


--047d7b111f5f64ab3104e15522fe-- From roman@telurix.com Fri Jul 12 13:23:59 2013 Return-Path: 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 E2C1B21F9EDA for ; Fri, 12 Jul 2013 13:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.856 X-Spam-Level: X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 YBAJZMGLufIf for ; Fri, 12 Jul 2013 13:23:54 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5762421F9E98 for ; Fri, 12 Jul 2013 13:23:54 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so963657wgg.0 for ; Fri, 12 Jul 2013 13:23:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=yXikOyxI/Lek+6A6Aj0AMpU85XB87tCvnHgVA+ZRZhM=; b=MyplBYAGJ5JL4hANcN3At1nPXLom2/u5WZ64v3N95QRpFcBDC/Ga0xIkueIa2hpJGJ VfbBPjjky2jDQpWtpdkeP5/0EuWCD1/yXv+aZVrS9W6GK3U8foh8FzBuqSnmRpGE6pNX WWVyB8+ItvLmFSQgnYKuRZXt6eLcOw+1i6ccafyC5pfB4+Ndk+gZjapTsmA5/F8AeEKn grEUWDzDiLitjzKcwqWbnNsgVvDA66eitfbZkxkia89L4i/qAfVr2pel2dn7q2zWaFbh s6zP6a+S5vsCChNLvBGPMlmlkrbjI7olnhNGXoHOv3J5fwUrGGXWumATd1FyApFHUVqO g7pA== X-Received: by 10.180.75.80 with SMTP id a16mr2707216wiw.3.1373660629034; Fri, 12 Jul 2013 13:23:49 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [2a00:1450:400c:c03::234]) by mx.google.com with ESMTPSA id b14sm5342898wic.8.2013.07.12.13.23.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 13:23:48 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so8426740wes.39 for ; Fri, 12 Jul 2013 13:23:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.21.209 with SMTP id x17mr2566568wie.47.1373660626845; Fri, 12 Jul 2013 13:23:46 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Fri, 12 Jul 2013 13:23:46 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jul 2013 16:23:46 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b874000b4895104e15649c5 X-Gm-Message-State: ALoCoQlNi3TtiuOpA9r6F8fTHPuv+jkwqfIl398Q2RysDj2KTATJAkMCKpdO4S0+y6ivDfHpMkDW Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 20:24:00 -0000 --047d7b874000b4895104e15649c5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 12, 2013 at 2:28 PM, Martin Thomson wrote: > That depends entirely on the nature of the instructions. Allowing for > extensibility is always really, really hard, but maybe there is enough > experience with SDP now that this sort of scenario could be supported. > > Unless my past 10 years of experience building SIP systems mislead me, the current way of dealing with SDP extensibility is to define all features supported by network or device, go through the interop with every new network or device you need to connect to, and then, when in doubt, put an SBC in front of it. We currently need to go through interop testing every time we setup a new connection with a new VoIP service provider, and this is for simple PSTN to VoIP G.711+RFC2833 calls. Adding an unusual codec, like getting a direct interconnect in AMR-WB to cell phone networks, or SILK to Skype, requires years of testing and still not typically available commercially. SIP interworking for anything more complex (like even simple video end points) is virtually non existent. So, I guess, we are building on a very solid foundation of interprable solutions which require extensive testing after every sneeze. _____________ Roman Shpount --047d7b874000b4895104e15649c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 12, 2013 at 2:28 PM, Martin Thomson = <martin.thomson@gmail.com> wrote:
That depends entirely on the nature of the instructions. = =A0Allowing for
extensibility is always really, really hard, but maybe there is enough
experience with SDP now that this sort of scenario could be supported.

<= br>
Unless my past 10 years of experience building SIP systems mi= slead me, the current way of dealing with SDP extensibility is to define al= l features supported by network or device, go through the interop with ever= y new network or device you need to connect to, and then, when in doubt, pu= t an SBC in front of it. We currently need to go through interop testing ev= ery time we setup a new connection with a new VoIP service provider, and th= is is for simple PSTN to VoIP G.711+RFC2833 calls. Adding an unusual codec,= like getting a direct interconnect in AMR-WB to cell phone networks, or SI= LK to Skype, requires years of testing and still not typically available co= mmercially. SIP interworking for anything more complex (like even simple vi= deo end points) is virtually non existent. So, I guess, we are building on = a very solid foundation of interprable solutions which require extensive te= sting after every sneeze.
_____________
Roman Shpount
=A0
--047d7b874000b4895104e15649c5-- From creslin@digium.com Fri Jul 12 15:02:41 2013 Return-Path: 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 B546421F9E24 for ; Fri, 12 Jul 2013 15:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 mzEUsE-yOoJt for ; Fri, 12 Jul 2013 15:02:36 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3B021F9D7C for ; Fri, 12 Jul 2013 15:02:34 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 13so7950344lba.2 for ; Fri, 12 Jul 2013 15:02:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=bRMU/RLolbjTRRUfCgj+pWy/JILV7Kr9paGM5O/Eems=; b=KENo0nM+600GpdW+A1e+03nzpbYEpIWN21aL/PdUrrcKlhpwuofw28MWdcvNjNL/JO C9TmCTp2WczandHVmw+1+IjPgOkQu5ffVVxwyIfG+ISb7gi0QlJ0ad+oI2DoRiuyfGH6 6QWeRDE2KRxOzwlOphdXxMSvEQgNVwJ1Y1gGmQhUHl3I8qll1UvWR7rW+XIMZnVlFHQJ vU0o9h4G/ctwWKCchXXVL7MiAJgsJmP6XvswDOOGtFqaqQC4ovLe3iCk1Gza3LzRbmnf antsIbRWoWAWeeuQl/nG12+HAzsHuZHfaYQBHfZMBd8s3oEzAZQAahUhfWhjbmknP8IT Jmmw== MIME-Version: 1.0 X-Received: by 10.112.235.104 with SMTP id ul8mr19988413lbc.36.1373666552901; Fri, 12 Jul 2013 15:02:32 -0700 (PDT) Received: by 10.112.141.161 with HTTP; Fri, 12 Jul 2013 15:02:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jul 2013 17:02:32 -0500 Message-ID: From: Matt Fredrickson To: Roman Shpount Content-Type: multipart/alternative; boundary=001a11c3c96eed040104e157aa1e X-Gm-Message-State: ALoCoQmCXKxxcSwVb29gzsSLH4Cr9lyvsbj/uNg3OXDjYeFC4/0g6a6PtA6Z8kAs8z0erEGD8pSC Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 22:02:41 -0000 --001a11c3c96eed040104e157aa1e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 12, 2013 at 3:23 PM, Roman Shpount wrote: > On Fri, Jul 12, 2013 at 2:28 PM, Martin Thomson wrote: > >> That depends entirely on the nature of the instructions. Allowing for >> extensibility is always really, really hard, but maybe there is enough >> experience with SDP now that this sort of scenario could be supported. >> >> > Unless my past 10 years of experience building SIP systems mislead me, the > current way of dealing with SDP extensibility is to define all features > supported by network or device, go through the interop with every new > network or device you need to connect to, and then, when in doubt, put an > SBC in front of it. We currently need to go through interop testing every > time we setup a new connection with a new VoIP service provider, and this > is for simple PSTN to VoIP G.711+RFC2833 calls. Adding an unusual codec, > like getting a direct interconnect in AMR-WB to cell phone networks, or > SILK to Skype, requires years of testing and still not typically available > commercially. SIP interworking for anything more complex (like even simple > video end points) is virtually non existent. So, I guess, we are building > on a very solid foundation of interprable solutions which require extensive > testing after every sneeze. > I think much of it goes back to supporting a specific subset of SDP for a core set of use cases. In the Asterisk world, we generally try to support nearly anything and everything that operates within our set of core use cases. But once you trespass too far outside of them, you can only fall back to support the parts of the session description that are interpretable by your implementation. Given all of the different devices that we have come to interoperate with over the years (just with SDP, not even necessarily with SIP or other higher layer signalling), I too fear that a lack of specific restraints on what is permissible within SDP as utilized within WebRTC will cause interoperability and fragmentation problems, at least in more advanced use cases. Matthew Fredrickson --001a11c3c96eed040104e157aa1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 12, 2013 at 3:23 PM, Roman Shpount <roman@t= elurix.com> wrote:
On Fri, Jul 12, 2013 at 2:28 PM, Martin Thomson <martin.thomson@gm= ail.com> wrote:
That depends entirely on the nature of the instructions. =A0Allowing f= or
extensibility is always really, really hard, but maybe there is enough
experience with SDP now that this sort of scenario could be supported.


Unless my = past 10 years of experience building SIP systems mislead me, the current wa= y of dealing with SDP extensibility is to define all features supported by = network or device, go through the interop with every new network or device = you need to connect to, and then, when in doubt, put an SBC in front of it.= We currently need to go through interop testing every time we setup a new = connection with a new VoIP service provider, and this is for simple PSTN to= VoIP G.711+RFC2833 calls. Adding an unusual codec, like getting a direct i= nterconnect in AMR-WB to cell phone networks, or SILK to Skype, requires ye= ars of testing and still not typically available commercially. SIP interwor= king for anything more complex (like even simple video end points) is virtu= ally non existent. So, I guess, we are building on a very solid foundation = of interprable solutions which require extensive testing after every sneeze= .

I think much of it goes back to supp= orting a specific subset of SDP for a core set of use cases. =A0In the Aste= risk world, we generally try to support nearly anything and everything that= operates within our set of core use cases. =A0But once you trespass too fa= r outside of them, you can only fall back to support the parts of the sessi= on description that are interpretable by your implementation.

Given all of the different devices that we have come to= interoperate with over the years (just with SDP, not even necessarily with= SIP or other higher layer signalling), I too fear that a lack of specific = restraints on what is permissible within SDP as utilized within WebRTC will= cause interoperability and fragmentation problems, at least in more advanc= ed use cases.

Matthew Fredrickson
--001a11c3c96eed040104e157aa1e-- From hadriel.kaplan@oracle.com Fri Jul 12 17:00:26 2013 Return-Path: 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 7DAEA11E8132 for ; Fri, 12 Jul 2013 17:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 CqRMBrgZ1xyD for ; Fri, 12 Jul 2013 17:00:19 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id CCE8E11E812A for ; Fri, 12 Jul 2013 17:00:19 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6D00Hx8029388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Jul 2013 00:00:17 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6D00GxJ013360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jul 2013 00:00:16 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6D00GRP021342; Sat, 13 Jul 2013 00:00:16 GMT Received: from [192.168.2.6] (/184.61.127.93) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 12 Jul 2013 17:00:15 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 12 Jul 2013 20:00:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 00:00:26 -0000 On Jul 11, 2013, at 2:08 PM, Martin Thomson = wrote: > I can see some implied outcomes for some of the items. Would it help > to list some (aspirational) goals. >=20 > On 11 July 2013 09:51, Ted Hardie wrote: >> Should SDES be part of WebRTC security practice and, if so, how? >> Presentations: 30 minutes >> Discussion: 40 minutes >=20 > Are the chairs confident that this topic can be resolved in this time? > We managed to fritter a similar amount of time away without > conclusion in the past. I can see how you plan to accommodate > overruns, but that just opens the possibility more time-wasting. How > do we ensure that this discussion actually concludes? I can't guarantee that we'll conclude of course, but I'm hopeful we will = get to a hum/vote one way or the other. In my presentation I plan to = propose a compromise, for example. I think those against SDES will be = ok with the compromise, but I'm not sure about those who want SDES. -hadriel From hadriel.kaplan@oracle.com Sat Jul 13 11:07:28 2013 Return-Path: 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 BCBBD21F9D5C for ; Sat, 13 Jul 2013 11:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 Z9nwADs7vJ8v for ; Sat, 13 Jul 2013 11:07:22 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1539421F9CAC for ; Sat, 13 Jul 2013 11:07:22 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6DI7K7A009067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 13 Jul 2013 18:07:21 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6DI7JbX020055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Jul 2013 18:07:20 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6DI7JjD001412 for ; Sat, 13 Jul 2013 18:07:19 GMT Received: from [192.168.2.6] (/184.61.127.93) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 13 Jul 2013 11:07:19 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Sat, 13 Jul 2013 14:07:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 18:07:29 -0000 Howdy, Someone's asked me to explain the compromise I plan on presenting in = Berlin now, so we have more time to argue over it or chew on it. The = reason I was going to wait is because I wanted to explain how I got to = the point of thinking such a compromise would make sense. So I'll try = to do that in this email, which will make this email long. Nothin' much = I can do about that. Obviously this is all my personal opinion, not that of my employer, and = not a statement claiming to be objective fact, etc. Background: I think many people would agree that SDES has some benefits compared to = DTLS for those of us wishing to interface to the SIP world. Some of = those benefits are commercial/cost factors, some are more tangible like = reducing early media clipping. Whether you agree with such benefits or = not, so long as WebRTC could support SDES in a sufficiently-secure = manner, there'd be less concern over having it. Most of the arguments = against SDES have been directed at whether it could in fact be = "sufficiently secure". Personally I find most of the arguments against = it being secure enough to be essentially FUD, and/or also apply to = DTLS-SRTP. On the flip-side, I think the commercial/cost factor for SDES is not a = strong cause, because I believe the market will bear whatever the extra = cost may be. (I wasn't sure of this 2 years ago when this all started, = but I'm fairly confident of it now) And I think having only DTLS-SRTP = as MTI would have a marketing benefit for WebRTC as a technology, which = I value highly. Given those personal feelings, I didn't much care either way, so long as = a decision was made - although I still preferred having SDES to avoid = the early media clipping problem. So when I was going to present on = this topic back in the Vancouver meeting, my last slide basically said: = "If we support SDES and it turns out later we were wrong, we can always = rescind it". This was based on the notion that browsers get updated all = the time, especially for security issues. But later it occurred to me that's actually the Achilles' heel of = supporting SDES in WebRTC, for those of us wanting to gateway this stuff = to SIP. Imagine if it turns out we were wrong, and some = expected-or-unexpected vulnerability is exploited against some large = WebRTC service provider, and makes the news/slashdot. Browser vendors = would instantly have new code removing SDES support, and browsers in = devices would be updated virtually overnight - some users may take a = long time to upgrade their specific browsers on their specific devices - = but many of them would do so within days. That would be untenable for a = WebRTC service provider. Even the smaller Enterprises take a long time = to upgrade code on their servers, so even for them changing their = gateways to suddenly support DTLS-SRTP would be unrealistic. Imagine = what it would be for larger providers, who might even have to deploy = more servers to handle the sudden additional overhead of DTLS-SRTP. = Meanwhile a growing percentage of their users can no longer use the = service. That's bad mojo. The things that a WebRTC-to-SIP service provider can control, and = arguably the much larger use-case for this stuff to begin with, are not = really true "browsers" anyway - they're web-based-framework device Apps, = provided by the service provider to begin with. I.e., the apps they = build using web application framework things like PhoneGap/Cordova, = Appcelerator Titanium, etc. I mean using a real Browser is nice for = ad-hoc stuff, like being able to click on a "talk to a rep" button on a = website, or a webex/meetecho type thing; but for real communication = "service", whether it be as a subscriber of a traditional carrier, or = Skype, or an employee of an Enterprise, or a call-center attendant, or = whatever - for those most people would never want to have to open a = browser just to receive/make calls. They'd give you an app to use = instead. So it's the app use-case that would benefit the most from SDES, = especially for issues like media clipping. And the app use-case doesn't = have the security concerns nor concerns for unforeseen overnight = updates. The Compromise: So given that background, I was planning to propose that the security = doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a = statement that web-based application frameworks SHOULD also support = SDES. (with text about why and how, etc.) I don't think this is too controversial, because web-based frameworks = are never beholden to following browser behavior anyway - they're used = to build a native application, and native applications have a very = different security/threat model in practice. They're written for a = specific purpose, and installed by users from known sources for that = known purpose. Technically, afaik, nothing we do in RTCWEB WG or W3C's = WEBRTC group have any requirements/mandates for native applications = anyway - an app maker would just ignore something they don't think = applies to them - but I think web-based frameworks do generally try to = follow W3C models for Javascript APIs, and will likely read the IETF = RFCs for the media-layer stuff too. So I think having this SHOULD = statement would be beneficial. Or if the WG prefers, we could even write a separate doc on what a = web-based framework maker should consider supporting/not-supporting. (I = can imagine a few other things they might want to offer that a browser = can't) -hadriel From stefan.lk.hakansson@ericsson.com Sat Jul 13 11:39:26 2013 Return-Path: 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 865AD21F9DDC for ; Sat, 13 Jul 2013 11:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_00=-2.599, 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 zEbxFh-z9QMx for ; Sat, 13 Jul 2013 11:39:21 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DA0A821F9DED for ; Sat, 13 Jul 2013 11:39:20 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-8f-51e19ed4b7c8 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1B.32.11907.4DE91E15; Sat, 13 Jul 2013 20:39:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Sat, 13 Jul 2013 20:39:16 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Peter Thatcher Thread-Topic: [rtcweb] Draft agenda for IETF 87 Thread-Index: AQHOflbnoSh5pMdyC0qq6yOZjrenEA== Date: Sat, 13 Jul 2013 18:39:16 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3134DB@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C311367@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre6VeQ8DDd6cNbXomMxmce3MP0aL a8tfs1qs/dfO7sDiMeX3RlaPnbPusnss2FTqsWTJT6YAligum5TUnMyy1CJ9uwSujOsv/zAX 3NKveLjhIVsD41rVLkZODgkBE4neh2dZIWwxiQv31rN1MXJxCAkcZZTYefwuO4SziFHi/p8T TCBVbAKBElv3LWADsUUENCUmT24G62YWaGWUWHRFsYuRg0NYQE9iTkMkiCkioC/xebMxRLWe RP+BTcwgNouAqsTFnm9gnbwCvhIP/p9hhVi1hlniyNQZjCAJRqCDvp9awwQxXlzi1pP5TBCH Ckgs2XOeGcIWlXj5+B/UA0oSjUueQJ2jJ3Fj6hQ2CFtbYtnC18wQywQlTs58wjKBUXQWkrGz kLTMQtIyC0nLAkaWVYwcxanFSbnpRgabGIERc3DLb4sdjJf/2hxilOZgURLn3aJ3JlBIID2x JDU7NbUgtSi+qDQntfgQIxMHp1QDIzvXN8UkCdN9Npvfrlr/YRqfTdt3w8YWDeVHkdu4bJyn aGcKP51RKSmp2h8b1/PtpfW0hHNZjDWeNQtuKZ/ax15aWDJphSfb6h+qHa5L3C9eupLmarWp 2ujNevHC6DP3r4bLi/JvnZT0W2qSVv/5K2wn2l477/O0TmlX9tCdoix42/dsYdgbJZbijERD Leai4kQAL4tXCGYCAAA= Cc: "Cullen Jennings \(fluffy\)" , "" Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 18:39:26 -0000 On 7/12/13 7:19 PM, Peter Thatcher wrote:=0A= >=0A= >=0A= >=0A= > On Fri, Jul 12, 2013 at 12:35 AM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > On 7/11/13 9:38 PM, Martin Thomson wrote:=0A= > > On 11 July 2013 12:04, Cullen Jennings (fluffy) >=0A= > > wrote:=0A= > >> On Jul 11, 2013, at 10:35 AM, Emil Ivov >=0A= > >>> In you last mail on the subject you mentioned that we will be=0A= > >>> discussing No Plan in Berlin together with plans A and B. Could= =0A= > >>> we please add this to the agenda?=0A= > >>=0A= > >> No. We believe that conversation needs to happen in the W3C WebRT= C=0A= > >> WG. I expect to see a message from W3C chairs on this at some=0A= > >> point.=0A= > >=0A= > > I'm a little nervous about this. Where does the decision on the= =0A= > > separation of responsibilities (API vs. SDP) get made?=0A= >=0A= > (I have not been able to confer with any of the other chairs, so this= is=0A= > just my personal opinion):=0A= >=0A= > To me it seems pretty straightforward to a certain point:=0A= >=0A= > * The SDP (if we opt to continue using SDP for this purpose) that goe= s=0A= > on the signaling wire between the browsers is defined by IETF (and by= =0A= > the rtcweb WG I presume even though MMUSIC seems to have some stake)= =0A= >=0A= > * JS APIs to:=0A= > ** Apply an SDP (e.g. received on the signaling channel) to the brows= er=0A= > ** Hand an SDP generated by the browser over to the application (for= =0A= > transmission over the signaling wire presumably)=0A= > ** Influencing/modifying the contents of the SDP=0A= > * All belongs to the W3C WebRTC=0A= >=0A= >=0A= > Would it make sense to change this list to say the following?=0A= >=0A= > * JS APIs to:=0A= > ** Apply a SessionDescription (created by SDP; eg received on the=0A= > signaling channel or built by JS) to the browser=0A= > ** Hand a SessionDescription (serializable to SDP) generated by the=0A= > browser over to the application (for=0A= > transmission over the signaling wire presumably or for immediately=0A= > applying with setLocalDescription for some local effect)=0A= > ** Influencing/modifying the contents of the SessionDescription (and=0A= > thus, SDP, when serialized to SDP)=0A= > * All belongs to the W3C WebRTC=0A= =0A= That might well be a better way to put it.=0A= =0A= >=0A= >=0A= > My changes highlight a few things:=0A= > 1. The API (setLocalDescripiton, setRemoteDescription, creatOffer, etc)= =0A= > doesn't work with SDP directly. It works with RTCSessionDescription=0A= > objects. It just happens to be that currently the only way to interact= =0A= > with RTCSessionDescription objects is through SDP. I think it's worth=0A= > remembering that distinction.=0A= >=0A= > 2. SDP does not necessarily go over the wire. It only necessarily=0A= > goes through the API between JS and browser. I think it's worth=0A= > remembering that distinction.=0A= >=0A= > 3. Calling setLocalDescription with a new SessionDescription object can= =0A= > have purely local effects that don't need to be sent over the wire. I=0A= > think it's worth remembering those cases.=0A= >=0A= >=0A= > What seems unclear to me is where we define what modifications to the= =0A= > SDP that are allowed - and when. Even though the ambition is to have= =0A= > APIs that makes SDP mangling an exception, we will still see that=0A= > happening.=0A= >=0A= >=0A= > I think advanced JS apps are going to use every control knob they can=0A= > get to, whether it's anticipated and well-supported or not. I think=0A= > there's a good chance that a a popular WebRTC web app will use some SDP= =0A= > mangling that wasn't anticipated, but happened to work, but then the=0A= > browser can't remove it because it will break certain websites. It=0A= > could get even worse if someone writes a popular WebRTC wrapper library= =0A= > that uses tricky SDP mangling that is then used by lots of websites.=0A= > Certain SDP mangling techniques might end up becoming a defacto=0A= > standard API that can't be removed, even if it was originally a bug. Or= =0A= > worse, one browser will have to implement the SDP mangling or even the=0A= > bugs of another, because WebRTC apps have come to rely on them.=0A= >=0A= > In fact, it's already the case that Chrome and Firefox support far=0A= > different SDP manglings. I don't think any web apps rely on that yet,=0A= > but it's only a matter of time before someone figures out "hey, if I=0A= > mangle the SDP on this browser this way and on that browser that way, I= =0A= > can do things I couldn't do otherwise". Or worse, an advanced web app=0A= > developer says "hey, I can make this work well on browser X via SDP=0A= > mangling, but not on browser Y, so I'll put a 'best used with Browser X'= =0A= > icon on my website". Then that someone writes an abstraction on top of=0A= > that, and then maybe shares that with others, and it goes from there.=0A= >=0A= > I think we're in a race with web developers to see if they'll figure out= =0A= > SDP mangling before we provide a way to avoid SDP mangling. Who do you= =0A= > think moves faster?=0A= =0A= Let's go over to the public-webrtc W3C space and work on this.=0A= =0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > > _______________________________________________ rtcweb mailing lis= t=0A= > > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= > >=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= >=0A= =0A= From stefan.lk.hakansson@ericsson.com Sat Jul 13 11:40:32 2013 Return-Path: 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 4E69021F9E40 for ; Sat, 13 Jul 2013 11:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 Ov1m61goqMmt for ; Sat, 13 Jul 2013 11:40:26 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E900E21F9E3D for ; Sat, 13 Jul 2013 11:40:25 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-22-51e19f186e96 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1F.26.19388.81F91E15; Sat, 13 Jul 2013 20:40:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Sat, 13 Jul 2013 20:40:24 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Peter Thatcher Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOeDFbTNRhHYI3NkSZeqhrbqmeQg== Date: Sat, 13 Jul 2013 18:40:23 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3134EC@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30D110@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvra7E/IeBBq239S2m77OxuLb8NavF 2n/t7A7MHuca3rN7LNhU6rFkyU+mAOYoLpuU1JzMstQifbsErowtM20KZqlUbGpsY29gXCPd xcjJISFgIvFw9Qp2CFtM4sK99WwgtpDAYUaJGfezIOxFjBIfVliD2GwCgRJb9y0AqxER0JSY PLmZFcRmFkiSeL+8hQnEFhaoklh++BjQTA6gmmqJJf3lEOV6El0Xt7KA2CwCqhKN7WvAynkF fCWezfgPVM4FtOo+u0Tj26NgRYxA93w/BVHELCAucevJfCaIOwUkluw5zwxhi0q8fPyPFcJW kmhc8gTqHj2JG1OnsEHY2hLLFr5mhlgmKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiZM9N zMxJLzffxAiMi4NbfhvsYNx0X+wQozQHi5I472a9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGM8KbxQ8dq3xjsk9P70DfhbSRvtmn5w+1e6qWkdfqORG3Vm1C69P7E9XbrvK8uOTp5PM jyexAi41EqI9t2cn3PlybuuRstutHI4LWfXWzjO6P5vvmcjrws3LrauXKHQqKJvWpXdqxrA1 XrS3O5nLo6AUekvOKvNY09VLNjYN7y7G2j3T0YuwVmIpzkg01GIuKk4EAJDjGMtZAgAA Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 18:40:32 -0000 On 7/12/13 7:32 PM, Peter Thatcher wrote:=0A= >=0A= >=0A= >=0A= > On Tue, Jul 9, 2013 at 4:26 AM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > On 2013-07-09 12:18, I=F1aki Baz Castillo wrote:=0A= > > 2013/7/9 Stefan H=E5kansson LK >:=0A= > >> I want to be very clear and careful on what I say. So I am=0A= > repeating:=0A= > >>=0A= > >> * My comment that I think Eric is right in that there is=0A= > consensus on=0A= > >> providing APIs that allow most use-cases to be met without SDP=0A= > mangling=0A= > >> is meant only in that context: SDP O/A is kept (and=0A= > PeerConnection more=0A= > >> or less as is and so on).=0A= > >=0A= > > Hi Stefan,=0A= > >=0A= > > You insist that "there is consensus on keeping SDP O/A but=0A= > providing a=0A= > > better API".=0A= >=0A= > I must be expressing myself quite badly, because the message seems no= t=0A= > to get through.=0A= >=0A= > * I think we have consensus on adding API that allows most use-cases = to=0A= > be met without SDP mangling (given that SDP O/A is kept naturally)=0A= >=0A= > * We discussed last year an alternative API that did not use SDP at a= ll=0A= > (and did not use PeerConnection). The decision at that time was to=0A= > continue developing the API based on PeerConnection and SDP O/A.=0A= >=0A= > Have not stated anything more than that.=0A= >=0A= >=0A= > Thank you for clarifying, Stefan. It's often very difficult for those=0A= > of us who weren't there to understand what was consensus, and what=0A= > wasn't, and what was decided and what was decided and what wasn't. It=0A= > seems that if you ask 10 people, you get 10 different answers.=0A= >=0A= >=0A= > In other words, it's hard to see much consensus on what we have=0A= > consensus on.=0A= >=0A= >=0A= > So thank you for your clarifications. It's probably not a very fun job= =0A= > for you :). Along with that, I have two more questions for you:=0A= >=0A= >=0A= > 1. You said we have consensus on adding API that allows most use-cases= =0A= > to be met without SDP mangling. Since that point in time has there been= =0A= > in any progress in adding such APIs? Can you give me a rough feel for=0A= > how much time has passed, how many proposals have been made, how many=0A= > have been accepted, and how many have been implemented? I think it's=0A= > great that we'll do this "someday", but I'd like to get a feel for how=0A= > far away "someday" is. Thanks in advance.=0A= >=0A= > 2. You said we have consensus against an alternative API. Was that=0A= > consensus against any additions to the API that would allow JS to bypass= =0A= > SDP, or was that a consensus against just that particular alternative=0A= > API? I'd like to get a feel for how many people voted for "no; let's=0A= > not go down that specific road" vs. "no; we cannot go on any road but=0A= > this one". I think there's a big difference between the two. Thanks=0A= > again in advance.=0A= >=0A= >=0A= > By the way, Ted asked us to move discussions about the API to=0A= > public-webrtc, so should we do that now?=0A= =0A= Yes. I will respond there (probably tomorrow).=0A= =0A= >=0A= >=0A= >=0A= > Stefan=0A= >=0A= > > Given current discussions IMHO it is clear there is not=0A= > > such a consensus (not at all). Or may be you are just talking abou= t=0A= > > two years ago in some IETF meeting (if so I'm sorry).=0A= > >=0A= > > Please review the results in=0A= > >=0A= > https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkH= MSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1=0A= > >=0A= > > Bad for advanced stuff: 94%=0A= > > OK for 1.0: 40%=0A= > >=0A= > > IMHO such a result indicates all but "let's keep SDP O/A and=0A= > improve a=0A= > > bit the API" (I mean now, in July 2013).=0A= > >=0A= > >=0A= > > Best regards.=0A= > >=0A= > >=0A= > >=0A= > > --=0A= > > I=F1aki Baz Castillo=0A= > > >=0A= > >=0A= >=0A= > _______________________________________________=0A= > rtcweb mailing list=0A= > rtcweb@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= >=0A= =0A= From bernard_aboba@hotmail.com Sat Jul 13 14:02:36 2013 Return-Path: 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 76F9D21F9E0C for ; Sat, 13 Jul 2013 14:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 6-AQmWzvwgVe for ; Sat, 13 Jul 2013 14:02:30 -0700 (PDT) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7645D21F9DB4 for ; Sat, 13 Jul 2013 14:02:30 -0700 (PDT) Received: from BLU169-W122 ([65.55.116.73]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 13 Jul 2013 14:02:30 -0700 X-TMN: [JCIVvn3mGd4n+2nK+DVcx5ifP7aw36aq] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_01c938cf-2a92-4fe6-85ae-639d68afd89d_" From: Bernard Aboba To: Hadriel Kaplan , "rtcweb@ietf.org" Date: Sat, 13 Jul 2013 14:02:29 -0700 Importance: Normal In-Reply-To: References: , , , MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jul 2013 21:02:30.0163 (UTC) FILETIME=[49835630:01CE800C] Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 21:02:36 -0000 --_01c938cf-2a92-4fe6-85ae-639d68afd89d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hadriel -- I think you've brought up a critical point=2C which is very worth keeping i= n mind throughout the discussions in IETF RTCWEB. That is that WebRTC is r= eally two distinct innovations -- one=2C a profile of "RAI 2.0" functionali= ty=2C defining a core set of RTP functionality developed over the last deca= de (e.g. end-to-end security=2C adaptive HD codecs=2C AVPF=2C etc.)=2C and = the other=2C a set of Javascript APIs for Web browsers defined by the W3C. = IMHO=2C the "RAI 2.0" aspect is likely to prove more important (and long= -lived) than the W3C WEBRTC API aspect. =20 Since the "RAI 2.0" profile developed by the IETF RTCWEB WG is likely to li= ve on way beyond the useful life of the W3C WEBRTC APIs=2C it is critical t= hat the protocol profiles not be distorted so as to cater to API concerns t= hat will be difficult to justify=2C let alone remember=2C a decade from now= . If the damage brought about by an SDP-based API could be restricted sol= ely to Web browsers without reflecting itself in expected "on the wire" beh= avior=2C I would care a lot less about it. After all=2C the Internet knows= how to deal with bad designs - it just "treats them as damage and routes = around them". So to the extent that IETF RTCWEB can contain the SDP API = swamp we'll all be better off -- and the swamp will be that much easier to = drain down the road once it becomes clear to all that nobody really wants t= o live in that part of town anyway. =20 As you state=2C the vast majority of customers I talk to are interested pri= marily in the "RAI 2.0" aspects of WebRTC=2C and only secondarily=2C if at = all=2C in the W3C JS APIs. Given the displacement of feature phones by sma= rtphones=2C the growth in availability of wireless data as well as the incr= easing availability of connectivity that can support interactive video (all= areas of very rapid growth over the next few years)=2C the focus of realti= me communications app developers I talk to is not on browser=2C but on the = development of native applications. And unless HTML5-based approaches such= as Firefox OS gain traction=2C that focus is likely to remain. =20 Given this=2C the most frequent request I hear is for a usable mobile SDK t= hat can offer protocol compatibility with WebRTC implementations on browser= s. To succeed=2C that mobile SDK had better not look anything like the W3C= WEBRTC API=2C and it also better support extensibility. In reality=2C all= that the IETF RTCWEB profile defines is the core set of functionality -- t= hat set of features that MUST be supported to enable interoperability. How= ever=2C there is a lot more that a developer might want to have available f= or their particular application. That might include a codec (such as AMR-N= B) or a security variant such as SDES/SRTP. Since as you note many develo= pers aren't going to be using the W3C WEBRTC APIs anyway=2C whether those a= dditional functions are supported in the W3C APIs is largely irrelevant - a= nd so are discussions about whether this or that additional feature needs t= o be a "SHOULD" or a "MAY". =20 > So given that background=2C I was planning to propose that the security d= oc keep DTLS-SRTP as the only MTI mechanism for browsers=2C BUT to add a st= atement that web-based application frameworks SHOULD also support SDES. (wi= th text about why and how=2C etc.) >=20 > I don't think this is too controversial=2C because web-based frameworks a= re never beholden to following browser behavior anyway - they're used to bu= ild a native application=2C and native applications have a very different s= ecurity/threat model in practice. They're written for a specific purpose= =2C and installed by users from known sources for that known purpose. Tech= nically=2C afaik=2C nothing we do in RTCWEB WG or W3C's WEBRTC group have a= ny requirements/mandates for native applications anyway - an app maker woul= d just ignore something they don't think applies to them - but I think web-= based frameworks do generally try to follow W3C models for Javascript APIs= =2C and will likely read the IETF RFCs for the media-layer stuff too. So I= think having this SHOULD statement would be beneficial. = --_01c938cf-2a92-4fe6-85ae-639d68afd89d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hadriel --

I think you've brought up a critical point=2C which is very worth = keeping in mind throughout the discussions in IETF RTCWEB.  =3BThat is = that WebRTC is really two distinct innovations -- one=2C a profile of "RAI = 2.0" functionality=2C defining a core set of RTP functionality developed ov= er the last decade (e.g. end-to-end security=2C adaptive HD codecs=2C AVPF= =2C etc.)=2C and the other=2C a set of Javascript APIs for Web browsers def= ined by the W3C.  =3B =3BIMHO= =2C  =3Bthe "RAI 2.0" aspect is likely to prove more important (and lon= g-lived) than the W3C WEBRTC API aspect.  =3B

Since the "RAI 2.0" profile developed by the IETF RTCWEB WG is l= ikely to live on way beyond the useful life of the W3C WEBRTC APIs=2C it is= critical that the protocol profiles not be distorted so as to cater to API= concerns that will be difficult to justify=2C let alone remember=2C a deca= de from now.  =3B If the dam= age brought about by an SDP-based API could be restricted solely to Web bro= wsers without reflecting itself in expected "on the wire" behavior=2C I wou= ld care a lot less about it.  =3BAfter all=2C =3Bthe Internet knows how to deal with bad designs - =  =3Bit just "treats them as damage and routes around them".  =3B &n= bsp=3BSo to the extent that IETF RTCWEB can contain the SDP API swamp we'll= all be better off -- and the swamp will be that much easier to drain down = the road once it becomes clear to all that nobody really wants to live in t= hat part of town anyway.  =3B

As yo= u state=2C the vast majority of customers I talk to are interested primaril= y in the "RAI 2.0" aspects of WebRTC=2C and only secondarily=2C if at all= =2C in the W3C JS APIs.  =3BGiven the displacement of feature phones by= smartphones=2C the growth in availability of wireless data as well as the = increasing availability of connectivity that can support interactive video = (all areas of very rapid growth over the next few years)=2C the focus of re= altime communications app developers I talk to is not on browser=2C but on = the development of native applications.  =3BAnd unless HTML5-based appr= oaches such as Firefox OS gain traction=2C that focus is likely to remain. =  =3B =3B

<= /span>
Given this=2C the most= frequent request I hear is for a =3Busable mobile SDK that can offer protocol compatibility with WebRT= C implementations on browsers.  =3BTo succeed=2C that mobile SDK had be= tter not look anything like the W3C WEBRTC API=2C and it also better suppor= t extensibility.  =3BIn reality=2C all that the IETF RTCWEB profile def= ines is the core set of functionality -- that set of features that MUST be = supported to enable interoperability.  =3BHowever=2C there is a lot mor= e that a developer might want to have available for their particular applic= ation.  =3BThat might includ= e a codec (such as AMR-NB) or a security variant such as SDES/SRTP.  = =3B Since as you note many developers aren't going to be using the W3C WEBR= TC APIs anyway=2C whether those additional functions are supported in the W= 3C APIs is largely irrelevant - and so are discussions about whether this o= r that additional feature needs to be a "SHOULD" or a "MAY".  =3B


>=3B So given that background= =2C I was planning to propose that the security doc keep DTLS-SRTP as the o= nly MTI mechanism for browsers=2C BUT to add a statement that web-based app= lication frameworks SHOULD also support SDES. (with text about why and how= =2C etc.)
>=3B
>=3B I don't think this is too controversial=2C b= ecause web-based frameworks are never beholden to following browser behavio= r anyway - they're used to build a native application=2C and native applica= tions have a very different security/threat model in practice. They're wri= tten for a specific purpose=2C and installed by users from known sources fo= r that known purpose. Technically=2C afaik=2C nothing we do in RTCWEB WG o= r W3C's WEBRTC group have any requirements/mandates for native applications= anyway - an app maker would just ignore something they don't think applies= to them - but I think web-based frameworks do generally try to follow W3C = models for Javascript APIs=2C and will likely read the IETF RFCs for the me= dia-layer stuff too. So I think having this SHOULD statement would be bene= ficial.

= --_01c938cf-2a92-4fe6-85ae-639d68afd89d_-- From stefan.lk.hakansson@ericsson.com Sat Jul 13 23:58:42 2013 Return-Path: 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 DBFB121F9CD7 for ; Sat, 13 Jul 2013 23:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 vuJG7LWoL2KV for ; Sat, 13 Jul 2013 23:58:36 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3105521F9CD1 for ; Sat, 13 Jul 2013 23:58:36 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-c7-51e24c1a4b3f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AC.04.06741.A1C42E15; Sun, 14 Jul 2013 08:58:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Sun, 14 Jul 2013 08:58:34 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Bernard Aboba Thread-Topic: [rtcweb] A compromise for SDES Thread-Index: AQHOf/PYrRNaPAl1IEWTwZbyw5tH2g== Date: Sun, 14 Jul 2013 06:58:33 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3139D3@ESESSMB209.ericsson.se> References: , , , Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvra6Uz6NAg0/t+hb7l1xmtvi06ROz xdp/7ewOzB6Pe86weSxZ8pPJ4+PTWywBzFFcNimpOZllqUX6dglcGefOP2UsWMVZ8eDKb9YG xiPsXYycHBICJhKb10xkg7DFJC7cWw9kc3EICRxmlFi4+SkzhLOIUeJ+Ww8jSBWbQKDE1n0L gKo4OEQEdCX+dhmBhJkFQiU2th9kBQkLC2hLfDxZBRIWEdCRaL+wkBHC1pP4eHMVWCeLgKrE m2OZIGFeAV+Jw9v+QG3azCRxdMszsNsYge75fmoNE8R4cYlbT+YzQdwpILFkz3lmCFtU4uXj f6wQtpJE45InrBD1ehI3pk5hg7C1JZYtfM0MsUxQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBk WcXInpuYmZNebriJERgdB7f81t3BeOqcyCFGaQ4WJXHeTXpnAoUE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwlu335JOxXFNjsFvMdKnE5wuhHHMOyaw2rE60Vn/n/zV3hvSdfVxGR5l5jG9/ fqaa5/DGZu2pul08b7XEPGPure3+vix6hcXBiaZLGtd4PP95aRbz0w6Z4kSBNTOupcV+eT4t +ZOw0lfXRi2za3zPD7440M1QGGu25M/t9XOYs7z0F6m7XIozVWIpzkg01GIuKk4EAMoI341c AgAA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 06:58:43 -0000 On 7/13/13 11:02 PM, Bernard Aboba wrote:=0A= > Hadriel --=0A= >=0A= > I think you've brought up a critical point, which is very worth keeping= =0A= > in mind throughout the discussions in IETF RTCWEB. That is that WebRTC= =0A= > is really two distinct innovations -- one, a profile of "RAI 2.0"=0A= > functionality, defining a core set of RTP functionality developed over=0A= > the last decade (e.g. end-to-end security, adaptive HD codecs, AVPF,=0A= > etc.), and the other, a set of Javascript APIs for Web browsers defined= =0A= > by the W3C.IMHO, the "RAI 2.0" aspect is likely to prove more=0A= > important (and long-lived) than the W3C WEBRTC API aspect.=0A= =0A= =0A= I think that the Javascript APIs are going to be very important, but I =0A= fully agree that the "RAI 2.0" profile defined will be used beyond =0A= browsers. And I think that the more self contained (i.e. not dependent =0A= on other signaling during operation) we can make that RAI 2.0 profile =0A= the better.=0A= =0A= So I am again arguing for pushing things like pause/resume signaling to =0A= RTP/RCTP, and not depend on out of band exchanges of signaling messages.=0A= =0A= =0A= =0A= From roman@telurix.com Sun Jul 14 07:38:19 2013 Return-Path: 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 7978311E8124 for ; Sun, 14 Jul 2013 07:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 vvQM8EMxYGNL for ; Sun, 14 Jul 2013 07:38:14 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 01C4021F9A2E for ; Sun, 14 Jul 2013 07:38:13 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so9504780wes.10 for ; Sun, 14 Jul 2013 07:38:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NcVSsknYE9vXm7RYFg257gHwnO8hJHssBUjBqvxX4RA=; b=GTFFVWRKeSMEh7ESLcSdLB2izLLv1HR6cFHR9ou5dPjln0BlOUAAfr+8U2gbsQ/TgT FSJmUzy42ksb7TYaFIimQBEvaJD87CDqaR/qB2Z0Tjab0yvXBLHFyeFuHZplJUCRXUMm Nwx2y+OUal1w/WOOgrH8iWRkDlVU2tCwnKQxgz6o2CcH6m8ho0rsY7E11dU4EX2tIhlD hfj1PfB1Zb95MInQciGij+cY2/5qgijjhlj+XDx7IrI3o+CMud+BSD3Lb9TXd4uf5WP7 x6Fa4n41ree2SDOUe5ztbaAl8Ov0eM7+6DpG4Sq4LAIo/9pnSofAsZzh6Xby5Pl6fq5o 2WFQ== X-Received: by 10.181.12.80 with SMTP id eo16mr6411381wid.44.1373812693025; Sun, 14 Jul 2013 07:38:13 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [2a00:1450:400c:c03::236]) by mx.google.com with ESMTPSA id fs8sm14871625wib.0.2013.07.14.07.38.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 07:38:11 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so9491488wes.13 for ; Sun, 14 Jul 2013 07:38:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.184.12 with SMTP id eq12mr6292547wic.8.1373812690839; Sun, 14 Jul 2013 07:38:10 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Sun, 14 Jul 2013 07:38:10 -0700 (PDT) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C3139D3@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C3139D3@ESESSMB209.ericsson.se> Date: Sun, 14 Jul 2013 10:38:10 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= , Hadriel Kaplan , Bernard Aboba Content-Type: multipart/alternative; boundary=001a11c3669e6cf06804e179b1d5 X-Gm-Message-State: ALoCoQlkY1C46/w/oyQQvnUjCilK++O38O8xspEg1QmGTfsXflCVBUjvUce6emgDRWa5qx+Hi4hD Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 14:38:19 -0000 --001a11c3669e6cf06804e179b1d5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Jul 14, 2013 at 2:58 AM, Stefan H=E5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 7/13/13 11:02 PM, Bernard Aboba wrote: > > Hadriel -- > > > > I think you've brought up a critical point, which is very worth keeping > > in mind throughout the discussions in IETF RTCWEB. That is that WebRTC > > is really two distinct innovations -- one, a profile of "RAI 2.0" > > functionality, defining a core set of RTP functionality developed over > > the last decade (e.g. end-to-end security, adaptive HD codecs, AVPF, > > etc.), and the other, a set of Javascript APIs for Web browsers defined > > by the W3C.IMHO, the "RAI 2.0" aspect is likely to prove more > > important (and long-lived) than the W3C WEBRTC API aspect. > > > I think that the Javascript APIs are going to be very important, but I > fully agree that the "RAI 2.0" profile defined will be used beyond > browsers. And I think that the more self contained (i.e. not dependent > on other signaling during operation) we can make that RAI 2.0 profile > the better. > > This point, even though valid, might have unintended consequences. For instance, if support for RTP based real time text in web browsers is questionable, due to other ways to implement it via existing communications channels, it should probably be part of "RAI 2.0". I think there are going to be quite a few features, which will not be part of core webrtc functionality which will fall into "RAI 2.0" category. Discussing these features can slow down this group even more then it already is, and is most likely be outside of this group charter. Furthermore, according to the same logic, Hadriel's compromise can be boiled down to not supporting SDES in WebRTC, with all the other language essentially discussing things that will not controlled by WebRTC drafts and lay outside this group charter. _____________ Roman Shpount --001a11c3669e6cf06804e179b1d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 14, 2013 at 2:58 AM, Stefan H=E5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
On 7/13/13 11:02 PM, Berna= rd Aboba wrote:
> Hadriel --
>
> I think you've brought up a critical point, which is very worth ke= eping
> in mind throughout the discussions in IETF RTCWEB. =A0That is that Web= RTC
> is really two distinct innovations -- one, a profile of "RAI 2.0&= quot;
> functionality, defining a core set of RTP functionality developed over=
> the last decade (e.g. end-to-end security, adaptive HD codecs, AVPF, > etc.), and the other, a set of Javascript APIs for Web browsers define= d
> by the W3C.IMHO, =A0the "RAI 2.0" aspect is likely to = prove more
=A0> important (and long-lived) than the W3C WEBRTC AP= I aspect.


I think that the Javascript APIs are going to be very important, but = I
fully agree that the "RAI 2.0" profile defined will be used beyon= d
browsers. And I think that the more self contained (i.e. not dependent
on other signaling during operation) we can make that RAI 2.0 profile
the better.


This point, even though valid, might h= ave unintended consequences. For instance, if support for RTP based real ti= me text in web browsers is questionable, due to other ways to implement it = via existing communications channels, it should probably be part of "R= AI 2.0". I think there are going to be quite a few features, which wil= l not be part of core webrtc functionality which will fall into "RAI 2= .0" category. Discussing these features can slow down this group even = more then it already is, and is most likely be outside of this group charte= r.

Furthermore, according to the same logic, Hadriel's= compromise can be boiled down to not supporting SDES in WebRTC, with all t= he other language essentially discussing things that will not controlled by= WebRTC drafts and lay outside this group charter.
_____________
Roman Shpount
=A0
--001a11c3669e6cf06804e179b1d5-- From rishi@turtleyogi.com Sun Jul 14 10:03:35 2013 Return-Path: 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 38C7821F9B0D for ; Sun, 14 Jul 2013 10:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 QcueHW2IpBo7 for ; Sun, 14 Jul 2013 10:03:30 -0700 (PDT) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id BBE1121F9ADE for ; Sun, 14 Jul 2013 10:03:30 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id ar20so23854720iec.21 for ; Sun, 14 Jul 2013 10:03:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=wGPYPD7mudvDTip9e43jaqVYePdmg7BHLEX+cF9Dy5g=; b=BgfOZeIWWqUcgGQgUtkWK76b64sl3I6jO/7zI7mHtDnujgnLtfxuum7RpCdMTzFHQD 1O9NzeNpQxncqpVxeO5RMEKjGuqmHgdS19bxIDtK7oJRoVVw9ye8gmrDLTgpfCGd69Eg jXozKbDOTd847ux79gNaJwwddpH+7CBO+UBIuOeSk2yyA4PkXtXmfuugtNtOro2ddkVQ 7RCzaUeUbLkDOSk56sacuZaVhns9BEqHDwzXbNSK2vU6fddy1bkM+TOjQSh50r2XgAhY yuV23qlrAP6EELhQ+Tcw7vXbxUt5p9wYbo71kd0H4TYVTIj4K5eUCK/cyyjeaGyGW6au uTRA== MIME-Version: 1.0 X-Received: by 10.42.79.142 with SMTP id r14mr16829041ick.51.1373821409869; Sun, 14 Jul 2013 10:03:29 -0700 (PDT) Received: by 10.64.231.36 with HTTP; Sun, 14 Jul 2013 10:03:29 -0700 (PDT) X-Originating-IP: [122.167.74.243] In-Reply-To: References: Date: Sun, 14 Jul 2013 22:33:29 +0530 Message-ID: From: Hrishikesh Kulkarni To: Bernard Aboba Content-Type: multipart/alternative; boundary=20cf3010ea091ee74604e17bb964 X-Gm-Message-State: ALoCoQlUsfDoE5emUKBCE3xlOdY9QvkXpLwDCmQX3EV39laB1S4qtTLCfLE4bMLfOKQen6qTfgcN Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 17:03:35 -0000 --20cf3010ea091ee74604e17bb964 Content-Type: text/plain; charset=ISO-8859-1 Very interesting discussion and important thread. I have a comment on JS API's. On Sun, Jul 14, 2013 at 2:32 AM, Bernard Aboba wrote: > Hadriel -- > > ..... > > As you state, the vast majority of customers I talk to are interested > primarily in the "RAI 2.0" aspects of WebRTC, and only secondarily, if at > all, in the W3C JS APIs. Given the displacement of feature phones by > smartphones, the growth in availability of wireless data as well as the > increasing availability of connectivity that can support interactive video > (all areas of very rapid growth over the next few years), the focus of > realtime communications app developers I talk to is not on browser, but on > the development of native applications. And unless HTML5-based approaches > such as Firefox OS gain traction, that focus is likely to remain. > > WebRTC JS API's has the potential to make video/audio based web apps the first class citizens of internet. Focus on interop at the media plane and signaling plane is important. But it is critical to focus and bring better JS API's to browser and browser frameworks. I am startup and many customers I talk to are asking for video web apps on Internet explorer which unfortunately is lacking as compared to Chrome and Firefox (both of which are available on mobile too). regards, Rishi OneKlikStreet.com > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf3010ea091ee74604e17bb964 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Very interesting discussion and important thread. I h= ave a comment on JS API's.

On Sun, = Jul 14, 2013 at 2:32 AM, Bernard Aboba <bernard_aboba@hotmail.com<= /a>> wrote:
Hadriel --

.....
<= div>
As you state, the vast majority of customers I talk to are int= erested primarily in the "RAI 2.0" aspects of WebRTC, and only se= condarily, if at all, in the W3C JS APIs. =A0Given the displacement of feat= ure phones by smartphones, the growth in availability of wireless data as w= ell as the increasing availability of connectivity that can support interac= tive video (all areas of very rapid growth over the next few years), the fo= cus of realtime communications app developers I talk to is not on browser, = but on the development of native applications. =A0And unless HTML5-based ap= proaches such as Firefox OS gain traction, that focus is likely to remain. = =A0=A0


WebRTC JS API&#= 39;s has the potential to make video/audio based web apps the first class c= itizens of internet. Focus on interop at the media plane and signaling plan= e is important. But it is critical to focus and bring better JS API's t= o browser and browser frameworks. I am startup and many customers I talk to= are asking for video web apps on Internet explorer which unfortunately is = lacking as compared to Chrome and Firefox (both of which are available on m= obile too).=A0

regards,
Rishi

--20cf3010ea091ee74604e17bb964-- From pthatcher@google.com Mon Jul 15 05:47:17 2013 Return-Path: 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 AAA3821F9FE2 for ; Mon, 15 Jul 2013 05:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.048, 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 Iay3-hb0INCF for ; Mon, 15 Jul 2013 05:47:16 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 887DD21F9EAF for ; Mon, 15 Jul 2013 05:47:16 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id ld11so11075238pab.8 for ; Mon, 15 Jul 2013 05:47:14 -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=1FbEERiIF2zJwO2bvXmiGBGFnp0yWUmHdx8wMfmS1S8=; b=C/boSMt3mKFhvfpDJSpwHd7lUe+uPybpMos6oeecrtxdb1gnLzDu5jnSd1xfHPrLGl /+IkmcKRJ4VmmXEXzp6M2iXRgWbVw8aG4E4WD3FFwnqA4ZeOhihN6+aaXcEClhlflE+c bkU9zHcgvq+DmzyNpdo6NWmwk487gmVfEQokAX+P/vV3xAJG3ALLq4OZFJkKFr1KNT5j EpZr3e4bgTTohyqmIZP9M/EVSSNlTCmAUZ6ecmoLT36PgBK3Xw48k1rCgGMmfAV8K/gO oHj8jHST/VR/4v0gplfU5QjgkFiduzlL/NxML92+wQfHsqEMGOh6kotHl+pjGvJY4e6u u5yw== 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=1FbEERiIF2zJwO2bvXmiGBGFnp0yWUmHdx8wMfmS1S8=; b=L6P1Z78uN+JyBrRZhNULFE7WtNTDJJFUOoGdcec4gBMGKRs87Ax+sOSVahk/vS6Jlp JLKDm9SM8K9Dt8RRH8gi/99/cbqj5SFptWIMsCX+XmgE4EoMUvOT9QqEIicYfbdeEEnF ZH5UoEU8PeoQ1jAeVQtKh9bLuphYUhuBwqDNCJDwhK6z3A5wYVFwm4IogTZpgGx970Wd dOfYjMrSet5c+uFSKg15ZlC/pMWpy0MciWPp//mdaH91D37Jwo8sn3V6AvxMplZUKAei L+xNInX7BSG+N+miP3x8mYYIQ437vHoqA+fTenXOeW2hP0lNnw5fAghwUyVPgo8tC9ao FXJg== X-Received: by 10.66.228.72 with SMTP id sg8mr55085092pac.45.1373892434364; Mon, 15 Jul 2013 05:47:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 15 Jul 2013 05:46:34 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Mon, 15 Jul 2013 05:46:34 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7b111cff82ace904e18c427f X-Gm-Message-State: ALoCoQmSBi++x2T5M2XBEboCr94mcS5r5h108T4HwEn5QqjymgA7YxTliLtnwpMxT12IU/nbOr3mYNgD/pN1tSuTr5JNCHz2UREp2StDPUVycFKZtdJXtG+KsGvIo/kB27SDOaK1zArPZC47NQnQ09N4TqG8Iy4ZuwGM7J7UXKWlIIHBoVLGzkWFRT+TanoXrGDrJWaslAR+ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 12:47:17 -0000 --047d7b111cff82ace904e18c427f Content-Type: text/plain; charset=UTF-8 On Sat, Jul 13, 2013 at 2:02 PM, Bernard Aboba wrote: > Hadriel -- > > I think you've brought up a critical point, which is very worth keeping in > mind throughout the discussions in IETF RTCWEB. That is that WebRTC is > really two distinct innovations -- one, a profile of "RAI 2.0" > functionality, defining a core set of RTP functionality developed over the > last decade (e.g. end-to-end security, adaptive HD codecs, AVPF, etc.), and > the other, a set of Javascript APIs for Web browsers defined by the W3C. IMHO, > the "RAI 2.0" aspect is likely to prove more important (and long-lived) > than the W3C WEBRTC API aspect. > > Since the "RAI 2.0" profile developed by the IETF RTCWEB WG is likely to > live on way beyond the useful life of the W3C WEBRTC APIs, it is critical > that the protocol profiles not be distorted so as to cater to API concerns > that will be difficult to justify, let alone remember, a decade from now. > If the damage brought about by an SDP-based API could be restricted > solely to Web browsers without reflecting itself in expected "on the wire" > behavior, I would care a lot less about it. After all, the Internet > knows how to deal with bad designs - it just "treats them as damage and > routes around them". So to the extent that IETF RTCWEB can contain the > SDP API swamp we'll all be better off -- and the swamp will be that much > easier to drain down the road once it becomes clear to all that nobody > really wants to live in that part of town anyway. > > > As you state, the vast majority of customers I talk to are interested > primarily in the "RAI 2.0" aspects of WebRTC, and only secondarily, if at > all, in the W3C JS APIs. Given the displacement of feature phones by > smartphones, the growth in availability of wireless data as well as the > increasing availability of connectivity that can support interactive video > (all areas of very rapid growth over the next few years), the focus of > realtime communications app developers I talk to is not on browser, but on > the development of native applications. And unless HTML5-based approaches > such as Firefox OS gain traction, that focus is likely to remain. > > Given this, the most frequent request I hear is for a usable mobile SDK > that can offer protocol compatibility with WebRTC implementations on > browsers. To succeed, that mobile SDK had better not look anything like > the W3C WEBRTC API, and it also better support extensibility. > Chrome's implementation of WebRTC, which can be found at webrtc.org, has a mobile SDK that can be used to build mobile apps (Android and iOS, at least). Some well-known and popular RTC mobile apps are in large part built on that code and can interop to a degree with browsers. So in some sense, you already have what you want. The big problem is that the high-level API offered by that SDK exactly matches the one in the browser, which means it's the gross SDP-based one. And none of the mobile apps I know, beyond an example app, use that API, or have plans to, precisely because it's gross. Instead, as far as I know, they dig deeper into the code and avoid that part. (why jam everything through SDP if you don't have to?). I think the optimal scenario for us to target is to define a good API that is the same between mobile and web browsers. I think that would help developers the most. Making such a "web and mobile" API is probably out of scope for any WG, but I think that if we defined a good (non SDP-based) API for the browser, it could easily be exposed as a native SDK (just like it is now), but be much less gross and more usable. I don't know if such a thing (a good API for both mobile and web) can realistically ever happen, but in the meantime, you can at least pick up the code at webrtc.org and make a mobile app. It's open source, too, so if you want to make a better API than what's there, go ahead and write one :). In reality, all that the IETF RTCWEB profile defines is the core set of > functionality -- that set of features that MUST be supported to enable > interoperability. However, there is a lot more that a developer might want > to have available for their particular application. That might include a > codec (such as AMR-NB) or a security variant such as SDES/SRTP. Since as > you note many developers aren't going to be using the W3C WEBRTC APIs > anyway, whether those additional functions are supported in the W3C APIs is > largely irrelevant - and so are discussions about whether this or that > additional feature needs to be a "SHOULD" or a "MAY". > FYI, the code at webrtc.org supports SDES/SRTP, and while it doesn't have support for AMR-NB (as far as I know), it does have a system for adding new codecs, so you could theoretically take an implementation of AMR-NB and compile it in yourself to make a mobile app. It may not be very easy, but it is possible. > > > > So given that background, I was planning to propose that the security > doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a > statement that web-based application frameworks SHOULD also support SDES. > (with text about why and how, etc.) > > > > I don't think this is too controversial, because web-based frameworks > are never beholden to following browser behavior anyway - they're used to > build a native application, and native applications have a very different > security/threat model in practice. They're written for a specific purpose, > and installed by users from known sources for that known purpose. > Technically, afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have > any requirements/mandates for native applications anyway - an app maker > would just ignore something they don't think applies to them - but I think > web-based frameworks do generally try to follow W3C models for Javascript > APIs, and will likely read the IETF RFCs for the media-layer stuff too. So > I think having this SHOULD statement would be beneficial. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b111cff82ace904e18c427f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Jul 13, 2013 at 2:02 PM, Bernard Aboba &l= t;bernard_ab= oba@hotmail.com> wrote:
Hadriel --

I think you&= #39;ve brought up a critical point, which is very worth keeping in mind thr= oughout the discussions in IETF RTCWEB. =C2=A0That is that WebRTC is really= two distinct innovations -- one, a profile of "RAI 2.0" function= ality, defining a core set of RTP functionality developed over the last dec= ade (e.g. end-to-end security, adaptive HD codecs, AVPF, etc.), and the oth= er, a set of Javascript APIs for Web browsers defined by the W3C. =C2=A0=C2= =A0IMHO, =C2=A0the "RAI 2.0" aspec= t is likely to prove more important (and long-lived) than the W3C WEBRTC AP= I aspect. =C2=A0

Since the "RAI 2.0" profile developed by the IETF R= TCWEB WG is likely to live on way beyond the useful life of the W3C WEBRTC = APIs, it is critical that the protocol profiles not be distorted so as to c= ater to API concerns that will be difficult to justify, let alone remember,= a decade from now. =C2=A0 If the dam= age brought about by an SDP-based API could be restricted solely to Web bro= wsers without reflecting itself in expected "on the wire" behavio= r, I would care a lot less about it. =C2=A0After all,=C2=A0the Internet knows how to deal with bad designs - =C2= =A0it just "treats them as damage and routes around them". =C2=A0= =C2=A0So to the extent that IETF RTCWEB can contain the SDP API swamp we&#= 39;ll all be better off -- and the swamp will be that much easier to drain = down the road once it becomes clear to all that nobody really wants to live= in that part of town anyway. =C2=A0



=C2=A0
As you state, the vast majority of customer= s I talk to are interested primarily in the "RAI 2.0" aspects of = WebRTC, and only secondarily, if at all, in the W3C JS APIs. =C2=A0Given th= e displacement of feature phones by smartphones, the growth in availability= of wireless data as well as the increasing availability of connectivity th= at can support interactive video (all areas of very rapid growth over the n= ext few years), the focus of realtime communications app developers I talk = to is not on browser, but on the development of native applications. =C2=A0= And unless HTML5-based approaches such as Firefox OS gain traction, that fo= cus is likely to remain. =C2=A0=C2=A0

Given this, the most frequent request I hear is for a<= span style=3D"font-size:12pt">=C2=A0usable mobile SDK that can offer protoc= ol compatibility with WebRTC implementations on browsers. =C2=A0To succeed,= that mobile SDK had better not look anything like the W3C WEBRTC API, and = it also better support extensibility. =C2=A0

Chrome's implementation of= WebRTC, which can be found at webrtc.org= , has a mobile SDK that can be used to build mobile apps (Android and iOS, = at least). =C2=A0Some well-known and popular RTC mobile apps are in large p= art built on that code and can interop to a degree with browsers. =C2=A0So = in some sense, you already have what you want.

The big problem is that the high-level API offered by t= hat SDK exactly matches the one in the browser, which means it's the gr= oss SDP-based one. =C2=A0And none of the mobile apps I know, beyond an exam= ple app, use that API, or have plans to, precisely because it's gross. = =C2=A0Instead, as far as I know, they dig deeper into the code and avoid th= at part. (why jam everything through SDP if you don't have to?). =C2=A0=

I think the optimal scenario for us to target is to def= ine a good API that is the same between mobile and web browsers. =C2=A0I th= ink that would help developers the most. =C2=A0Making such a "web and = mobile" API is probably out of scope for any WG, but I think that if w= e defined a good (non SDP-based) API for the browser, it could easily be ex= posed as a native SDK (just like it is now), but be much less gross and mor= e usable. =C2=A0

I don't know if such a thing (a good API for both m= obile and web) can realistically ever happen, but in the meantime, you can = at least pick up the code at webrtc.org a= nd make a mobile app. =C2=A0It's open source, too, so if you want to ma= ke a better API than what's there, go ahead and write one :).





=
In reality, all t= hat the IETF RTCWEB profile defines is the core set of functionality -- tha= t set of features that MUST be supported to enable interoperability. =C2=A0= However, there is a lot more that a developer might want to have available = for their particular application. =C2=A0That might include a codec (such as AMR-NB) or a security variant such a= s SDES/SRTP. =C2=A0 Since as you note many developers aren't going to b= e using the W3C WEBRTC APIs anyway, whether those additional functions are = supported in the W3C APIs is largely irrelevant - and so are discussions ab= out whether this or that additional feature needs to be a "SHOULD"= ; or a "MAY". =C2=A0

FYI, the code at webrtc.org supports SDES/SRTP, and while it doesn'= t have support for AMR-NB (as far as I know), it does have a system for add= ing new codecs, so you could theoretically take an implementation of AMR-NB= and compile it in yourself to make a mobile app. =C2=A0It may not be very = easy, but it is possible.
=C2=A0
<= div>

> So given that background, I was planning to propos= e that the security doc keep DTLS-SRTP as the only MTI mechanism for browse= rs, BUT to add a statement that web-based application frameworks SHOULD als= o support SDES. (with text about why and how, etc.)
>
> I don't think this is too controversial, because web-base= d frameworks are never beholden to following browser behavior anyway - they= 're used to build a native application, and native applications have a = very different security/threat model in practice. They're written for = a specific purpose, and installed by users from known sources for that know= n purpose. Technically, afaik, nothing we do in RTCWEB WG or W3C's WEB= RTC group have any requirements/mandates for native applications anyway - a= n app maker would just ignore something they don't think applies to the= m - but I think web-based frameworks do generally try to follow W3C models = for Javascript APIs, and will likely read the IETF RFCs for the media-layer= stuff too. So I think having this SHOULD statement would be beneficial.

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


--047d7b111cff82ace904e18c427f-- From internet-drafts@ietf.org Mon Jul 15 06:28:47 2013 Return-Path: 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 2C05A21E8082; Mon, 15 Jul 2013 06:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 GjALihbTBak8; Mon, 15 Jul 2013 06:28:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BED4921F9EDE; Mon, 15 Jul 2013 06:28:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715132846.9345.54571.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 06:28:46 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:28:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Security Considerations for WebRTC Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-05.txt Pages : 24 Date : 2013-07-15 Abstract: The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC". The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP-based soft phones) WebRTC communications are directly controlled by a Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-security-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-security-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 15 06:29:34 2013 Return-Path: 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 AA36E21E809F; Mon, 15 Jul 2013 06:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 FSPmRwtPP4gJ; Mon, 15 Jul 2013 06:29:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD2621F9971; Mon, 15 Jul 2013 06:29:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715132934.27097.34160.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 06:29:34 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:29:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : WebRTC Security Architecture Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-07.txt Pages : 43 Date : 2013-07-15 Abstract: The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC"). This document defines the security architecture for The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-security-arch-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ekr@rtfm.com Mon Jul 15 06:34:00 2013 Return-Path: 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 5D9B811E8103 for ; Mon, 15 Jul 2013 06:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.835 X-Spam-Level: X-Spam-Status: No, score=-100.835 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_51=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB18=0.131, USER_IN_WHITELIST=-100] 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 Fp2fJcsN+EIk for ; Mon, 15 Jul 2013 06:33:55 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0145A11E80F1 for ; Mon, 15 Jul 2013 06:33:54 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so6157946qcx.21 for ; Mon, 15 Jul 2013 06:33:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=01Og5VWelJvOd/HJEmNQLkQZwbd6ST9Bf3uHYC29sDg=; b=XwjZMvUdHMx+kgOzCBmArCmyqac51ozH/sh9TgULTDuRq4S0DTEkTHGFYvlLCK17F+ 7V9l5wC9Es5D94+elREB+vHz3q8X9s6lny4E6CqUfLft+ToRjOL0o72NG50tGCVNcqln ZR6b/NrXybimdKtqNiUG1htbckoIoAxjqwLr8sRVV0ElXlzpmZCXSYLjaz5Xabw3RomI hAfhTXuoH9GpfmzruLM8Za1MLjKDbRFXEAbCfs0v0pbjR76mdKQ5qx+a2+jUm9H+R/JV NSnZzcroI63jFRyorFXVljFiWD7+jXbr6E4fgdgSkKGQsen8KE7T5WcIUL0uGkuc8dre GMVA== X-Received: by 10.49.116.9 with SMTP id js9mr50968972qeb.73.1373895232249; Mon, 15 Jul 2013 06:33:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Mon, 15 Jul 2013 06:33:12 -0700 (PDT) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Mon, 15 Jul 2013 06:33:12 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6da78246f54a04e18ce9ab X-Gm-Message-State: ALoCoQnDnpWnjClQlAJTvB/oOJX7U6r3M3GEOssCSR52qWouFiLJ/gRk2sfRwTKB40OoyPStlLIx Subject: [rtcweb] Updated security documents X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:34:00 -0000 --047d7b6da78246f54a04e18ce9ab Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've just posted updated security documents reflecting most, but not all the last call comments. There's still a few TODOs I need to resolve F2F, (+ the SDES thing which I haven't done anything with, since we're discussing it in Berlin). Below is a consolidated response to people's comments. Please let me know if you think I haven't responded adequately to yours. DRAFT-IETF-RTCWEB-SECURITY -------------------------- WESTERLUND > I have reviewed the security draft (-04) as an individual and have the > following comments. Thanks for your comments. Responses below. > 1. Usage of acronym RTCWEB vs WebRTC. I thought we earlier had a > conclusion that we would use WebRTC as the acronym for the complete > solution? Am I remembering incorrectly? Changed, except when referring to the WG. > 2. I think the introduction should contain some pointer to the overview > draft for reverse lookup purpose if one stumbles on the document. Done. > 3. Section 3.1: > Similarly, while Flash SWFs can access the camera and microphone, > they explicitly require that the user consent to that access. > > Can you please expand the SWF acronym and perhaps add a reference? The acronym isn't very useful, since I think it refers ot "Shockwave Flash". I changed this to programs ("SWFs") Added a reference. > 4. Section 3.2: > Many other resources are accessible but isolated. For instance, > while scripts are allowed to make HTTP requests via the > XMLHttpRequest() API those requests are not allowed to be made to any > server, but rather solely to the same ORIGIN from whence the script > came.[RFC6454] (although CORS [CORS] and WebSockets [RFC6455] > provides a escape hatch from this restriction, as described below.) > > This above looks strange around the first period, which is followed by > RFC6454 reference. If is is a new sentence, the main sentence contains > only a reference. Fixed. > 5. Section 3.2 > This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks > on server B via the user's browser, which protects both the user > (e.g., from misuse of his credentials) and the server (e.g., from DoS > attack). > > I think one can make clear that the server one protects are B in the end > of the sentence. Although it reasonably clear from context, I think > writing it like this: > > This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks > on server B via the user's browser, which protects both the user > (e.g., from misuse of his credentials) and the server B (e.g., from > DoS attack). > > Is clearer. Changed. > 6. Section 4.1.1.3: > In both of the previous cases, the user has a direct relationship > (though perhaps a transient one) with the target of the call. > > Is it really the "target of the call" or is it the calling service that > the user has a direct relation ship with? I removed this section entirely since we decided to do nothing about this and I have seen other people be confused by it. > 7. Section 4.2.1: > > [[ OPEN ISSUE: Do we need some way of verifying the expected traffic > rate, not just consent to receive traffic at all.]] > > Regarding this issue, I think you could add something which makes this > not required, namely that by requiring congestion control of all flows > established by the browser, the browser tries to avoid persistent > congestion and any overload attack is less effective. The attack is more > in the vain of reducing any competing flows supported rate to a lower > fair share rate, which in worst case is below what is required to > support the service being the target of the attack. > > Thus I think the open issue question is a nice to have, but not required > feature. Agreed, and I think we have mostly come to consensus on this point, so I have removed the open issue. > 8. Section 4.2.4: > > I think this document is missing to discuss the privacy threats beyond > IP location privacy? I think that should be added, especially as we are > addressing some issues we know of. > > These other threats that we have discussed are associated with anonymous > calling services and linking and fingerprinting browsers or users with > anonymous calls. The threats we do know exist are for example RTCP CNAME > generation, DTLS certifcates, and API fingerprinting. I think these > needs to be raised as a threat. Added a privacy considerations section. -Ekr ------------------------------------------------- OHLSSON > Some minor comments on draft-ietf-rtcweb-security: Thanks. Responses below. > - Abstract > > This document defines the RTC-Web threat model and defines an > architecture which provides security within that threat model > > Isn't the architecture defined in draft-ietf-rtcweb-security-arch? Good catch. Fixed. > - Section 4.1.1.3, 3rd paragraph > > However, this obviously presents a privacy challenge, as sites which > host advertisements in IFRAMEs often learn very little about whether > individual users clicked through to the ads, or even which ads were > presented. > > What exactly is the privacy issue here? Is it that the hosting site > can eavesdrop on the call between the user and the advertiser since > IFRAMEs are not used? I removed this section. > - Section 4.3.1, 3rd paragraph > > In addition, the system MUST NOT provide any APIs to extract either > long-term keying material or to directly access any stored traffic keys. > > Does this mean that SDES is out of the picture or does the sentence onl= y > apply to DTLS(-SRTP)? I don't think this really impacts SDES, in context, but I tried to add some clarifying text. JOHNSON > Abstract and the duplicate text in Introduction: RTC-web turn into > either RTCWEB or WebRTC, with WebRTC being preferred. > > "some Web server" - slangy "a web server" Changed. > Figure 1: might also want to show WebSockets as this is becoming very > common and is mentioned later in the document without much context. I added WebSockets. > Also, do we want to show the signaling channel (the one referenced by > the W3C WebRTC spec that transports the SDP offers and answers between > browsers)? I think it clutters the diagram, but I added some text. > JS, popunder, and SWF are not defined in the draft Defined JS and SWF and rewrote to not use popunder. > 4.1.2. has a reference to draft-ietf-rescorla-rtcweb-generic-idp. > What is the status of this draft? Per WG discussion it has been folded into the security architecture. Fixed. > 4.3. RFC 3711 SRTP is not mentioned in the opening paragraph, which > seems strange, since it is the actual protocol providing the COMSEC > properties mentioned, rather then DTLS or DTLS-SRTP for media. Agreed. Fixed. > 4.3.1. Might be useful to mention that this is sometimes called a > "passive attack" whereas 4.3.2 is an "active attack". Fixed. > 4.3.2.2.There are a number of misleading statements about SAS in this > section which should be corrected. For example: > > "This SAS is designed to be read over the voice channel and if > confirmed by both sides precludes MITM attack." The SAS is to be > *compared* by the users - reading it out loud is only one possible > mechanism. Rewritten as: ZRTP uses a "short authentication string" (SAS= ) which is derived from the key agreement protocol. This SAS is designed to be compared by the users (e.g., read aloud over the the voice channel or transmitted via an out of band channel) and if confirmed by both sides precludes MITM attack. The intention is that the SAS is used once and then key continuity (though a different mechanism from that discussed above) is used thereafter. > "Moreover, it is possible for an attacker who controls the browser to > allow the SAS to succeed and then simulate call failure and reconnect, > trusting that the user will not notice that the "no SAS" indicator has > been set (which seems likely)." - I don't quite know what this means. > If SAS is used, the UI is the browser chrome, so if this is possible, > it is just a badly designed UI not a protocol failure or issue. Removed. > "Even were SAS secure if used, it seems exceedingly unlikely that > users will actually use it." - This reads like speculation. There are > users today using SAS, open source users and commercial users. One > thing is certain, if we don't provide SAS, then users will not use it. Yes, I think this is fair. I rewrote this to be a bit more neutral. Additionally, it is unclear that users will actually use an SAS. As discussed above, the browser UI constraints preclude requiring the SAS exchange prior to completing the call and so it must be voluntary; at most the browser will provide some UI indicator that the SAS has not yet been checked. However, it it is well-known that when faced with optional security mechanisms, many users simply ignore them . LMK if you still object. > The whole paragraph is about SAS, but then adds "or fingerprints" in > the last sentence. There are very significant differences between an > SAS and a fingerprint (which I will call a Way Too Long Authentication > String). If fingerprints are going to be discussed in this section, > then the differences between an SAS and a WTLAS need to be explained. Fair enough. I removed the graf. ABOBA ----- Bernard filed a bunch of issues: Issue 4: > It would be nice to see some editorial consistency among the document set= . > For example, the overview document uses the term "RTCWEB" to refer to the > IETF WG or protocol specifications whereas this document uses "RTC-Web". Changed to RTCWEB Issue 5: > There also needs to be some mechanism for the browser to verify that > the target of the traffic continues to wish to receive it. > Obviously, some ICE-based mechanism will work here, but it has been > observed that because ICE keepalives are indications, they will not > work here, so some other mechanism is needed. > > [[ OPEN ISSUE: Do we need some way of verifying the expected traffic > rate, not just consent to receive traffic at all.]] > > [BA] Since I believe we've figured this out, can we clean up the above > paragraph and OPEN ISSUE? Agreed. Rewrote anda dded a link to draft-muthu. > [Note: current thinking in the RTCWEB WG is not to support TCP and to > support SCTP over DTLS, thus removing the need for masking.] > > [BA] This section seems somewhat "overtaken by events" given that the data > channel will run over DTLS. How about the following? > > 4.2.2. Masking > > Once consent is verified, there still is some concern about > misinterpretation attacks as described by Huang et al.[huang-w2sp]. > Where TCP is used the risk is substantial due to the potential > presence of transparent proxies and therefore if TCP is to be used, > then WebSockets style masking MUST be employed. > > Since DTLS (with the anti-chosen plaintext mechanisms required by > TLS 1.1) does not allow the attacker to generate predictable > ciphertext, there is no need for masking of protocols running over > DTLS (e.g. SCTP over DTLS, UDP over DTLS, etc.). Done. > It is this consideration that makes an > automatic, public key-based key exchange mechanism imperative for > RTC-Web (this is a good idea for any communications security system) > and this mechanism SHOULD provide perfect forward secrecy (PFS). > > [BA] Do we mean "SHOULD support" PFS or "SHOULD use"? I don't believe > that DTLS/SRTP-EKT provides PFS. Also, is there any implication that th= e > user should be able to somehow influence whether PFS is required or not? Changed per discussion in the meeting. > 4.3.2. Protecting Against During-Call Attack > > Protecting against attacks during a call is a more difficult > proposition. Even if the calling service cannot directly access > keying material (as recommended in the previous section), it can > simply mount a man-in-the-middle attack on the connection, telling > Alice that she is calling Bob and Bob that he is calling Alice, while > in fact the calling service is acting as a calling bridge and > capturing all the traffic. While in theory it is possible to > construct techniques which protect against this form of attack, in > practice these techniques all require far too much user intervention > to be practical, given the user interface constraints described in > [abarth-rtcweb]. > > [BA] I think it's more than a user intervention/user interface issue. > Aside from snooping the signaling to see if the callee includes an > "isfocus" tag, how can the browser know if it is calling a conference > bridge or not? Personally, I'd remove the "in theory" sentence. I rewrote to describe how this could in principle happen with a fingerprint or an IdP. > 4.2.4. IP Location Privacy > > Note that as soon as the callee sends their ICE candidates, the > caller learns the callee's IP addresses. The callee's server > reflexive address reveals a lot of information about the callee's > location. In order to avoid tracking, implementations may wish to > suppress the start of ICE negotiation until the callee has answered. > In addition, either side may wish to hide their location entirely by > forcing all traffic through a TURN server. > > [BA] Might be useful to say explicitly that the concern about location > privacy is restricted to media; hiding the client's location from the We= b > server is handled by things like ToR, and signaling privacy is constrained > by the signaling protocol (e.g. SIP privacy, etc.). I added some material here. > #11: Security vs. Security-Arch > > At various points within the Security Architecture document, I had a > feeling of deju vu, encountering material that was also in the Security > doc. The overlap made me wonder if we should either move some material > from Arch to Security, or whether we couldn't live with a single doc > instead of two. I agree it's a bit awkward. I'm taking my guidance on one versus two documents from the chairs. If the WG wants me to merge, I'll do so. > Abstract > > All but the last sentence of the abstract is identical to that of the > Security document. Would it make some sense to shorten the abstract? > Also, references aren't allowed in abstracts. Shortened it. > Section 1 > > The first paragraph duplicates material from the abstract as well as > Section 1 of the Security doc, and figure 1 is also included in both docs. > However, the security doc doesn't discuss the multidomain case. Would i= t > make sense to move material from Section 1 of this document to the > security doc? If this were done, would we still need Section 1 in this > doc? As long as these are still separate documents, I'd like to keep this one as-is. I tried to keep the security document high-level, so I think this is probably the right split... > Section 5.2 > > This section, with its requirements on APIs, seemed similar in spirit to > Section 4.1 of the Security doc. Agreed. The idea of Section 4.1 is to provide analysis and this to provide nomative language. Agreed it's somewhat imperfect. > Section 5.4 > > Material in this section (such as the discussion of ToR) seems like it > might better belong in Section 4.2.4 of the Security doc. I added some more high-level material into the security doc. > #10: Additional Threats > > Aside from the threats described in the document, a few others come to > mind. It might be useful for the document to state explicitly why or wh= y > not these are out of scope: > > a. Live versus replayed streams. While you might have media security, > this doesn't tell you whether the stream is actually originating from a > device or is being replayed. > > b. Prank calling. While the document talks about permission to make > calls, it doesn't mention permission to receive or blocking of unwanted > calls. I added a section about malicious peers. DRAFT-IETF-RTCWEB-SECURITY-ARCH ------------------------------- > WESTERLUND > I have made an individual review of the security architecture document > version 6 and have the following comments. > > 1. In title and in other places, should we use WebRTC as the handle to > the complete solution? Done. > 2. Section 7.2 is wrongly labeled, I assume it is -04 version Unfortunately not. "Version -04 was a version control mistake. Please ignore." > 3. Section 4: > As is conventional in the Web, all identities are > ultimately rooted that system. > > I guess this should be ... rooted in that system? Fixed. > 4. Figure 4. The arrow between Bob's browser and Bob's IdP is missalinged= . Fixed. > 5. Section 4.1: > Because this is an audio/video call, it creates > two MediaStreams, one connected to an audio input and one connected > to a video input. > > I think this normally would be one mediaStream but with two > MediaStreamTracks. Agreed. > 6. Section 4.1: > If Bob agrees [I am ignoring early media for now], a PeerConnection > is instantiated with the message from Alice's side. > > I think you can remove the parenthesis. First of all I don't think it > relavant in the paragraph. Secondly, early media doesn't exist in the > context of a single peerConnection. Removed. > 7. Section 4.3 > > If Alice and Bob authenticated via their IdPs, > then they also know that the signaling service is not mounting a man- > in-the-middle attack on theor traffic. > > theor / their? Fixed. > 8. Section 5.1: > > It is RECOMMENDED that browsers which allow > active mixed content nevertheless disable RTCWEB functionality in > mixed content settings. [[ OPEN ISSUE: Should this be a 2119 MUST? > It's not clear what set of conditions would make this OK, other than > that browser manufacturers have traditionally been permissive here > here.]] > > I am actually quite worried about not making this a MUST. Mixed content > clearly causes significant security holes that I think really should be > avoided. Agreed. Changed per-wg discussion. > 9. Section 5.1, similarly I think this applies to the second open issue > in this section. Changed. If people disagree, please objec.t > 10. Section 5.3: > > [Note: > this document takes no position on the split between ICE in JS and > ICE in the browser. The above text is written the way it is for > editorial convenience and will be modified appropriately if the WG > decides on ICE in the JS.] The JS MUST NOT be permitted to control > the local ufrag and password, though it of course knows it. > > I think you can clean up this statement as there is consensus to leave > ICE in the browser. Done. > 11. Section 5.3: > A separate document will profile the ICE > timers to be used; see [I-D.muthu-behave-consent-freshness]. > > We should clarify the WG consensus on this document and the scope the > document has. I'm not sure I understand this. Is this a proposed change to the document or a WG action item? > 12. Section 5.4: > > API Requirement: The API MUST provide a mechanism for the calling > application JS to indicate that only TURN candidates are to be > used. This prevents the peer from learning one's IP address at > all. > > What about the ICE candidates related address information, that should > be mentioned I think also as possible risk of leaking and what to set it to. Good point! > 13. I am missing a discussion on how to avoid the linkage issues. I > think we need to point out the known sources to linkage that WebRTC > adds. I am aware of RTCP CNAMEs and as well as the certificate used in > DTLS(-SRTP). Their should be recommendations on how to avoid these issues= . See S 5.5 below. Are you looking for something else. > 14. Section 5.5 > [OPEN ISSUE: What should the settings be here? MUST?] > Implementations MAY support SDES for media traffic for backward > compatibility purposes. > > This needs to be resolved. I see no issues with retaining the > possibility for SDES and other schemes. I think however, the downgrade > issues may need more discussion here. This is a somewhat discussed in > the security considerations section later. I plan to hold off on this till after the discussion in Berlin. > 15. Section 5.5 > API Requirement: The API MUST provide a mechanism to indicate that a > fresh DTLS key pair is to be generated for a specific call. This > is intended to allow for unlinkability. Note that there are also > settings where it is attractive to use the same keying material > repeatedly, especially those with key continuity-based > authentication. > > I think this has to do with 13. For example should really the same > certificate be used with different origins, unless it is a intentionally > added endpoint certificate that provide verifiable source? No, it shouldn't be used with different origins except for thjat. > 16. Section 5.5 > [largely derived from > [I-D.kaufman-rtcweb-security-ui] > > Maybe this is more suitable in a contributors section instead of inline > in text. Done. > 17. Section 5.5: > > * The "security characteristics" MUST indicate the cryptographic > algorithms in use (For example: "AES-CBC" or "Null Cipher".) > > Does there need to be additional discussion or clarifications on high > level indications when one uses NULL cipher that doesn't provide > confidentiality? Good point. Added a new requirement here. > 18. Section 5.6.2: > > The details of the mechanism are described in the W3C API > specification, > > I think a reference needs to be added here. > > 19. Section 5.6.3 > Todo REF! Added. > 20. Section 5.6.4.1: > > The "algorithm" and digest values correspond directly to the > algorithm and digest in the a=3Dfingerprint line of the SDP. > > Should there be a reference to where a=3Dfingerprint is defined here? Done. > Also, does it need to be clarified what "algorithm" and digest > reference, the ABNF contructs or value for those parameters. I added "values" here. Is that what you were looking for? > 21. Section 5.6.4.2: > This SDP attribute is underspecified. No clear definition of what is > allowed, no IANA consideration section registering it. It's just a base64-encoded identity attribute. > Also, should this SDP attribute also carry the origin of the IdP? I just > wonder how a non browser can determine which IdP has been providing the > assertion. It's in the assertion. Do you think it would be better in the a=3Dline? > 22. Section 5.6.5.1 and following. > > I would like that all these JSON objects would have a bit more crisp > definitions. Sure, the JSON has certain limiations in what values can be > used, but it is unclear if the full UTF-8 values can be used in all > cases, or if there is restrictions on the URL provided, or if it should > be URI's in fact? OK. I will circle around with Ted (as a URL expert) and anyone else who feels expert to try to nail this down. > 23. I am missing a security discussion around the fact that I can claim > to have an IdP and load whatever JS code into the proxy. What security > implications deos this have. Section 5.6.5.2 does provide some basic > restrictions here. Are more needed? I tried to hit this in 5.7.4. Generally if you are a site you can always load new JS into the browser, so this is just part of the threat model. Can you give me an example of what you're looking for. > 24. Section 5.6.5.2.2: > > idp: A dictionary containing the domain name of the provider and the > protocol string > > What is the definition of dictionary here? I'm not sure enough of the terminology here. Isn't dictionary what we call JS associative-array type structures. > 25. Are there any time limits on responding to SIGN or Verify, or can > you get applications to hand simply by not responding to a IdP message? I would hope the browser would produce an error at some point, but I'm not sure we need to specify here. > 26. Section 5.6.5.2.3: > > Are the fields required to be included or not. This is a bit unclear. Currently it says: "MUST contain a message field consisting of a dictionary/hash with the following fields:" Would you like it to say "which MUST contain the following fields" > Section 27. Section 5.6.5.2.3: > Open issue to resolve. Please try to resolve this issue by talking to > some people. Agreed. This is now on my TODO list. > 27. Section 5.6.5.2.3.1 > > Open issue needing resolution. No opinion. Will raise this in Berlin. > 28. Section 5.7.2: > > Missing the linkability issues discussion here. Added some material. > 29. Section 5.7.2: > > Combined RTCWEB/Tor > implementations SHOULD arrange to route the media as well as the > signaling through Tor. [Currently this will produce very suboptimal > performance.] Done. > I think you can remove the parenthis but keep the text here. > > 30. Page 40 SDP example looks strange with no a=3Didenity attribute, > instead just the JSON object. Fixed. OHLSSON > When reading draft-ietf-rtcweb-security-arch I noticed a couple of things that might be missing: > > - According to section 4.3.2.4 in draft-ietf-rtcweb-security there shold > be a mechanism to verify that the remote browser has engaged a "secure > media mode". This mechanism is not (yet) described in the document. Good catch. I have to write something here but I haven't yet. > - Except for paragraph 6 in section 4.1, there is not much said about > the implications of the "secure media mode". This is referring to isolated streams, which is now in gUM. How much do you think I should say here? > - An enterprise network with an HTTP proxy may not want external web sites to > learn the IP addresses of its hosts using the PeerConnection API. I'm > not sure if this kind of attack is relevant or not. If it is then > it should be mentioned in Section 5.4. IP Location Privacy. Added some text. o > I also have some minor comments on the rest of the document: > > - Section 3, 1st paragraph > > The basic assumption of this architecture is that network resources > exist in a hierarchy of trust, rooted in the browser, which serves as > the user's TRUSTED COMPUTING BASE (TCB). > > The term "hierarchy of trust" is unclear in this context. Are there other > nodes in this hierarchy except for the browser and web server? I would claim browser, web server, idp (if any), other network elements. > - Section 3, 2nd paragraph > > This is a natural extension of the end-to-end principle. > > Perhaps it's just me but I don't understand what this end-to-end principle is. I just removed it since it doesn't add value. > - Section 4.3, 1st paragraph > > The total number of channels depends on the amount of > muxing; in the most likely case we are using both RTP/RTCP mux and > muxing multiple media streams on the same channel, in which case > there is only one DTLS handshake. > > Won't there be separate handshake for the data channel? My understanding was that we could mux the datachannel onto the same 5-tuple. > - Section 5.4, 1st paragraph > > [...] which leaks large amounts of location information, > especially for mobile devices. > > Why are mobile devices different in this aspect? They're not. Removed. > - Section 5.6.4 > > The SDP example contains RTP/AVP but I thought SRTP was made mandatory? Bit rot. Fixed. > - Section 5.6.5.1, 3rd paragraph > > All requests from the PeerConnection object MUST contain an "id" > field which MUST be unique for that PeerConnection object. Any > responses from the IdP proxy MUST contain the same id in response, > which allows the PeerConnection to correlate requests and responses. > > Couldn't the browser implementation handle the message routing > without the id field? This isn't about routing, it's about what happens if there are multiple outstanding queries. > - Section 5.6.5.1.1 > > The mandatory id field is missing in the example Fixed. > - Section 5.6.5.2.2 > > How is the assertion field transformed into the a=3Didentity attribute? > I guess you=B4re using some form of B64 encoding but this is not expain= ed > anywhere. It's earlier, but I added it. > - Section 5.6.5.2.3 > > I think the reason for including request_origin should be explained her= e > instead of in the end of the document. I added a forward reference instead to avoid breaking up the document flow. > - Section 5.7.1, 3rd paragraph > > WebCrypto API lacks a reference. > > - Section 5.7.4.5.2 > > Any IdP which uses cookies to persist logins will be broken > by third-party cookie blocking. > > Shouldn't it say "Any IdP which uses third-party cookies"? IdPs are inherently third-party in this context. > - Appendix A and B > > Both appendices appear unfinished. For example, ROAP is still mentioned > in othe BrowserID example and it's unclear what client credentials > Bob uses in the OAuth example. Agreed. I have a TODO to clean these up. JOHNSTON -------- > Again, lots of RTCWEB, RTCWeb, etc that should be WebRTC. Fixed. o> The document introduction seems to be specific to audio and video WebRTC sessions. Later, it becomes clear that the analysis applies to the data channel as well. This should be stated clearly up front and any differences between the two should be explained (i.e. DTLS vs SRTP encryption). I added a sentence in S 4.3. This is actually the first significant discussion of SRTP, so I think this works best. > "SIP or XMPP" - XMPP isn't a signaling protocol but Jingle is, so that is probably what should be mentioned, but Jingle doesn't use SDP. I just left it as SIP. > "Web sites whose origin we can verify (optimally via HTTPS, but in some cases because we are on a topologically restricted network, such as behind a firewall)" - what is the 2nd case - no verification? Verification using something other than HTTPS? I added "and can infer authentication from firewall behavior" > 3.1 middle para graph is basically saying that security policy can be applied after authentication - might be worth stating this after the Dr. Evil analogy. Added some text. > 4. "Specifically, Alice and Bob have relationships with > some Identity Provider (IdP) that supports a protocol such as OpenID > or BrowserID) that can be used to demonstrate their identity to other > parties." - needs one more ( to parse correctly. > > Figures 3 & 4. Would be better to have IdP1 and IdP2 to make clear that this can be 2 different providers. Also, Secure WebSockets should be shown with HTTPS. Done. > In Figures 3 & 4, media is shown as DTLS-SRTP when the media is in fact SRTP which is keyed with DTLS-SRTP. In fact, RFC 3711 is not even referenced, when it should be a normative reference, which is potentially very confusing and misleading for implementors. There are many places where DTLS-SRTP described as if it is more than a key agreement protocol for SRTP. I changed this to be "DTLS+SRTP", added a reference to RFC 3711, and went through each use of DTLS-SRTP for appropriateness, modifying where I thought necessary. Please let me know if there are places I missed. > Figure 4 is the Trapezoid of the overview and should be referenced as such. Added a back reference to figure 2. > JS is used but not defined. Defined it back in the intro. > 4.1 The first example in this document of microphone and webcam permissions is that of a permanent grant. Is this the model we want to encourage? Shouldn't the first mention be of the much safer per call grant? Later the per call grant is mentioned, but deep in the document. Rewritten. > 4.1 "This message is sent to the signaling server, e.g., by XMLHttpRequest[XmlHttpRequest] or by WebSockets [RFC6455] " Sentence is missing a period. Do we really mean HTTPS and Secure WebSockets here? I added "preferably over TLS". > 4.1 "This allows the browser to display a trusted element in the browser chrome indicating that a call is coming in from Alice." Can this assertion be made now, prior to the DTLS-SRTP handshake completing? If this identity assertion is made at this stage, then a different fingerprint shows up in the DTLS-SRTP handshake, does the browser chrome then indicate 'sorry, I made a mistake, it isn't Alice calling'? I think at that point you just show a network error. The identity assertion indicates that Alice was trying to call and if someone is attacking, then that's just a failure. > There are many cases of using [] instead of () for parentheical text. I try to use [] for Notes or open issues. > 4.2 ICE is not defined or referenced in its first occurance. Fixed in 4.1. > typo "theor" > > 5.1 "[[ OPEN ISSUE: Should this be a 2119 MUST? > It's not clear what set of conditions would make this OK, other than > that browser manufacturers have traditionally been permissive here > here.]] " > > [[ OPEN ISSUE:: Should we be more aggressive about this?]] > > Do these issues need to be discussed in a W3C document where browser expertise might help us do the right thing? I think we resolved this in Orlando and the document reflects what I think the consensus was. > 5.2 Do we really expect browsers to have X.509 certificates? Does anyone do this with DTLS-SRTP today? Do browsers have UI to manage these certs? No, we don't. This was a request from Martin because he was expecting servers might. I added some text to try to make that clear. > 5.2 The API and UI requirements and elsewhere - should these be in a W3C document instead of/in addition to this document? My sense is that IETF was responsible for the security analysis so they belong here. > 5.2 "Implementations which support some form of direct user authenticatio= n > SHOULD also provide a policy by which a user can authorize calls only > to specific counterparties." What is a counterparty? Changed to "communicating peers." > 5.3 ICE-Lite is not defined or referenced. Since this is a MUST, we need a normative reference - is it what is described as ICE Lite in RFC 5245 or draft-rescorla-mmusic-ice-lite? It's 5245 again. I added a cite. > Question: If a browser has multiple public/private keys, including an X.509 one, can the JS suggest which one to use for a particular PeerConnection? I think the answer needs to be yes here, but we probably need to clean up the W3C API a bit to match. > 5.5 Again, the media channel is secured using SRTP, not DTLS-SRTP, > which is one way to key SRTP. In the future, new and better key > agreements will be developed, and if we write all our specs assuming > one particular keying method, then they will become obsolete. Good point. Here is my new text which I hope is clearer: Implementations MUST implement SRTP [RFC3711]. Implementations MUST implement DTLS [RFC4347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST implement [I-D.ietf-tsvwg-sctp-dtls-encaps]. All media channels MUST be secured via SRTP. Media traffic MUST NOT be sent over plain (unencrypted) RTP. DTLS-SRTP MUST be offered for every media channel and MUST be the default; i.e., if an implementation receives an offer for DTLS-SRTP and SDES, DTLS-SRTP MUST be selected. All data channels MUST be secured via DTLS. > Section 5.6 with Appendix A reads like a completely separate > document. It is also very hard reading as there are lots of new > concepts and ideas. Should perhaps this be in a separate document? > The basic security architecture for WebRTC is unlikely to change, > but given that we have no experience with this IdP system, it seems > likely that it will evolve and perhaps change significantly, which > is an argument for a separate document. I agree the writing is a bit awkward. I'm rewriting App A to make it clearer and I'll see what I can do to about making S 5.6 merge better as well. > 5.6.4.2 Is this document defining a new SDP attribute? Shouldn't this be done in MMUSIC? I have a TODO here. Will consult with the chairs. > typos "implemementations" "termnating" "restrcitions" Fixed. > WebIntents mentioned without reference or explanation. WebIntents is OBE. Removed. > Missing normative reference: RFC 3711. Fixed. -Ekr --047d7b6da78246f54a04e18ce9ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've just posted updated security documents reflecting= most, but not all
the last call comments. There's still a few TODO= s I need to resolve
F2F, (+ the SDES thing which I haven't do= ne anything with, since we're
discussing it in Berlin).

Below is a consolid= ated response to people's comments. Please let me
know if you= think I haven't responded adequately to yours.


DRAFT-IETF-RTCWEB-SECURITY
-------------= -------------
=A0WESTERLUND
> I have reviewed the se= curity draft (-04) as an individual and have the
> following c= omments.

Thanks for your comments. Responses below.

> 1. Usage of acronym RTCWEB vs WebRTC. I th= ought we earlier had a
> conclusion that we would use WebRTC a= s the acronym for the complete
> solution? Am I remembering incorrectly?

= Changed, except when referring to the WG.


> 2. I think the introduction should contain some pointer to the = overview
> draft for reverse lookup purpose if one stumbles on the document.=

Done.


>= ; 3. Section 3.1:
> Similarly, while Flash SWFs can access the= camera and microphone,
> =A0 =A0they explicitly require that the user consent to that acce= ss.
>=A0
> Can you please expand the SWF acronym = and perhaps add a reference?

The acronym isn't= very useful, since I think it refers ot
"Shockwave Flash". I changed this to programs ("SWFs&qu= ot;)

Added a reference.

<= br>
> 4. Section 3.2:
> Many other resources are = accessible but isolated. =A0For instance,
> =A0 =A0while scripts are allowed to make HTTP requests via the
> =A0 =A0XMLHttpRequest() API those requests are not allowed to = be made to any
> =A0 =A0server, but rather solely to the same = ORIGIN from whence the script
> =A0 =A0came.[RFC6454] (although CORS [CORS] and WebSockets [RFC64= 55]
> =A0 =A0provides a escape hatch from this restriction, as= described below.)
>=A0
> This above looks strang= e around the first period, which is followed by
> RFC6454 reference. If is is a new sentence, the main sentence con= tains
> only a reference.

Fixed.


> 5. Section 3.2
> This= SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks
> =A0 =A0on server B via the user's browser, which protects bot= h the user
> =A0 =A0(e.g., from misuse of his credentials) and= the server (e.g., from DoS
> =A0 =A0attack).
>= =A0
> I think one can make clear that the server one protects are B in the e= nd
> of the sentence. Although it reasonably clear from contex= t, I think
> writing it like this:
>=A0
> This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks<= /div>
> =A0 =A0on server B via the user's browser, which protect= s both the user
> =A0 =A0(e.g., from misuse of his credentials= ) and the server B (e.g., from
> =A0 =A0DoS attack).
>=A0
> Is clearer.<= /div>

Changed.


&= gt; 6. Section 4.1.1.3:
> In bo= th of the previous cases, the user has a direct relationship
> =A0 =A0(though perhaps a transient one) with the target of the ca= ll.
>=A0
> Is it really the "target of the c= all" or is it the calling service that
> the user has a d= irect relation ship with?

I removed this section entirely since we decided to do = nothing
about this and I have seen other people be confused by it= .


> 7. Section 4.2.1:
>=A0
> [[ OPEN ISSUE: =A0Do we need some way of verifying t= he expected traffic
> =A0 =A0rate, not just consent to receive= traffic at all.]]
>=A0
> Regarding this issue, I= think you could add something which makes this
> not required, namely that by requiring congestion control of all = flows
> established by the browser, the browser tries to avoid= persistent
> congestion and any overload attack is less effec= tive. The attack is more
> in the vain of reducing any competing flows supported rate to a l= ower
> fair share rate, which in worst case is below what is r= equired to
> support the service being the target of the attac= k.
>=A0
> Thus I think the open issue question is a nice = to have, but not required
> feature.

= Agreed, and I think we have mostly come to consensus on this point,
so I have removed the open issue.


<= div>> 8. Section 4.2.4:
>=A0
> I think this do= cument is missing to discuss the privacy threats beyond
> IP l= ocation privacy? I think that should be added, especially as we are
> addressing some issues we know of.
>=A0
&g= t; These other threats that we have discussed are associated with anonymous=
> calling services and linking and fingerprinting browsers or= users with
> anonymous calls. The threats we do know exist are for example RTC= P CNAME
> generation, DTLS certifcates, and API fingerprinting= . I think these
> needs to be raised as a threat.

Added a privacy considerations section.

=
-Ekr

----------------------------------------= ---------
OHLSSON
> Some minor comments on draft-iet= f-rtcweb-security:

Thanks. Responses below.


<= /div>
> - Abstract
>=A0
> =A0 =A0 This doc= ument defines the RTC-Web threat model and defines an
> =A0 = =A0 architecture which provides security within that threat model
>=A0
> =A0 Isn't the architecture defined in draft= -ietf-rtcweb-security-arch?

Good catch. Fixed.


> - Section 4.1.1.3, 3rd paragraph<= /div>
>=A0
> =A0 =A0 However, this obviously presents a priv= acy challenge, as sites which
> =A0 =A0 host advertisements in= IFRAMEs often learn very little about whether
> =A0 =A0 indiv= idual users clicked through to the ads, or even which ads were
> =A0 =A0 presented.
>=A0
> =A0 What exac= tly is the privacy issue here? Is it that the hosting site
> = =A0 can eavesdrop on the call between the user and the advertiser since
> =A0 IFRAMEs are not used?

I removed this sect= ion.


> - Section 4.3.1, 3rd para= graph
>=A0
> =A0 =A0 In addition, the system MUST= NOT provide any APIs to extract either
> =A0 =A0 long-term keying material or to directly access any store= d traffic keys.
>=A0
> =A0 Does this mean that SD= ES is out of the picture or does the sentence only
> =A0 apply= to DTLS(-SRTP)?

I don't think this really impacts SDES, in context,= but I tried to add
some clarifying text.



JOHNSON
> Abstract and the dup= licate text in Introduction: RTC-web turn into
> either RTCWEB or WebRTC, with WebRTC being preferred.
&= gt;=A0
> "some Web server" - slangy "a web serv= er"

Changed.


> Figure 1: might also want to show WebSockets as this is becoming = very
> common and is mentioned later in the document without m= uch context.

I added WebSockets.


> Also, do we want to show the signaling chann= el (the one referenced by
> the W3C WebRTC spec that transport= s the SDP offers and answers between
> browsers)?

I think it clutters the diagram, but I added some text.


> JS, popunder, and SWF are not defi= ned in the draft

Defined JS and SWF and rewrote to= not use popunder.


> 4.1.2. has a reference to draft-iet= f-rescorla-rtcweb-generic-idp.
> What is the status of this dr= aft?

Per WG discussion it has been folded into the= security architecture.
Fixed.


> 4.3. =A0RFC 3711 S= RTP is not mentioned in the opening paragraph, which
> seems s= trange, since it is the actual protocol providing the COMSEC
>= properties mentioned, rather then DTLS or DTLS-SRTP for media.

Agreed. Fixed.


= > 4.3.1. Might be useful to mention that this is sometimes called a
> "passive attack" whereas 4.3.2 is an "active atta= ck".

Fixed.

> 4.3.2.2.There are = a number of misleading statements about SAS in this
> section = which should be corrected. =A0For example:
>=A0
>= =A0"This SAS is designed to be read over the voice channel and if
> =A0confirmed by both sides precludes MITM attack." =A0The SA= S is to be
> =A0*compared* by the users - reading it out loud = is only one possible
> =A0mechanism.

= Rewritten as:

=A0 ZRTP <xref target=3D"RFC6189"/> use= s a "short authentication string" (SAS) which is derived
=A0 from the key agreement protocol. This SAS is designed to be compared<= /div>
=A0 by the users (e.g., read aloud over the the voice channel or
=
=A0 transmitted via an out of band channel) and if confirmed by both s= ides precludes MITM
=A0 attack. The intention is that the SAS is = used once and then key
=A0 continuity (though a different mechanism from that discussed
=
=A0 above) is used thereafter.=A0


<= div>
> "Moreover, it is possible for an attacker who = controls the browser to
> allow the SAS to succeed and then simulate call failure and recon= nect,
> trusting that the user will not notice that the "= no SAS" indicator has
> been set (which seems likely).&qu= ot; - I don't quite know what this means.
> If SAS is used, the UI is the browser chrome, so if this is possi= ble,
> it is just a badly designed UI not a protocol failure o= r issue.

Removed.


> "Even were SAS secure if used, it seems exceedingly un= likely that
> users will actually use it." - This reads l= ike speculation. =A0There are
> users today using SAS, open so= urce users and commercial users. =A0One
> thing is certain, if we don't provide SAS, then users will no= t use it.

Yes, I think this is fair. I rewrote thi= s to be a bit more neutral.

=A0 =A0Additionally, i= t is unclear that users will actually use an SAS.
=A0 =A0As discussed above, the browser UI constraints preclude requiri= ng
=A0 =A0the SAS exchange prior to completing the call and so it= must be
=A0 =A0voluntary; at most the browser will provide some = UI indicator that the
=A0 =A0SAS has not yet been checked. However, it it is well-known that= when
=A0 =A0faced with optional security mechanisms, many users = simply
=A0 =A0ignore them <xref target=3D"whitten-johnny&= quot;/>.

LMK if you still object.=A0

> The whole paragraph is about SAS, but then adds "or = fingerprints" in
> the last sentence. =A0There are very s= ignificant differences between an
> SAS and a fingerprint (which I will call a Way Too Long Authentic= ation
> String). =A0If fingerprints are going to be discussed = in this section,
> then the differences between an SAS and a W= TLAS need to be explained.

Fair enough. I removed the graf.


ABOBA
-----
Bernard filed a bunch of = issues:

Issue 4:
> It would be nice t= o see some editorial consistency among the document set.
> For example, the overview document uses the term "RTCWEB&quo= t; to refer to the
> IETF WG or protocol specifications wherea= s this document uses "RTC-Web".

Changed = to RTCWEB


Issue 5:
=A0> There also ne= eds to be some mechanism for the browser to verify that
=A0> = =A0 =A0the target of the traffic continues to wish to receive it.
=A0> =A0 =A0Obviously, some ICE-based mechanism will work here, but it = has been
=A0> =A0 =A0observed that because ICE keepalives are indications, t= hey will not
=A0> =A0 =A0work here, so some other mechanism is= needed.
=A0>=A0
=A0> =A0 =A0[[ OPEN ISSUE: =A0Do= we need some way of verifying the expected traffic
=A0> =A0 =A0rate, not just consent to receive traffic at all.]]
=A0>=A0
=A0> [BA] Since I believe we've figured = this out, can we clean up the above
=A0> paragraph and OPEN IS= SUE?

Agreed. Rewrote anda dded a link to draft-muthu.
<= div>

> =A0[Note: =A0current thinking in the= RTCWEB WG is not to support TCP and to
> =A0support SCTP over= DTLS, thus removing the need for masking.]
>=A0
> =A0[BA] This section seems somewhat "overt= aken by events" given that the data
> =A0channel will run= over DTLS. How about the following?
>=A0
> =A04.= 2.2. Masking
>=A0
> =A0 =A0 Once consent is verified, there still i= s some concern about
> =A0 =A0 misinterpretation attacks as de= scribed by Huang et al.[huang-w2sp].
> =A0 =A0 Where TCP is us= ed the risk is substantial due to the potential
> =A0 =A0 presence of transparent proxies and therefore if TCP is t= o be used,
> =A0 =A0 then WebSockets style masking MUST be emp= loyed.
>=A0
> =A0 =A0 Since DTLS (with the anti-c= hosen plaintext mechanisms required by
> =A0 =A0 TLS 1.1) does not allow the attacker to generate predicta= ble
> =A0 =A0 ciphertext, there is no need for masking of prot= ocols running over
> =A0 =A0 DTLS (e.g. SCTP over DTLS, UDP ov= er DTLS, etc.).

Done.



> =A0 =A0 It is this consideration that makes an
> = =A0 =A0 automatic, public key-based key exchange mechanism imperative for
> =A0 =A0 RTC-Web (this is a good idea for any communications security s= ystem)
> =A0 =A0 and this mechanism SHOULD provide perfect for= ward secrecy (PFS).
>=A0
> =A0[BA] Do we mean &qu= ot;SHOULD support" PFS or "SHOULD use"? =A0I don't belie= ve
> =A0that DTLS/SRTP-EKT provides PFS. =A0Also, is there any implica= tion that the
> =A0user should be able to somehow influence wh= ether PFS is required or not?

Changed per discussi= on in the meeting.


> 4.3.2. Protecting Against During-Ca= ll Attack
>=A0
> =A0 =A0 Protecting against attac= ks during a call is a more difficult
> =A0 =A0 proposition. = =A0Even if the calling service cannot directly access
> =A0 =A0 keying material (as recommended in the previous section),= it can
> =A0 =A0 simply mount a man-in-the-middle attack on t= he connection, telling
> =A0 =A0 Alice that she is calling Bob= and Bob that he is calling Alice, while
> =A0 =A0 in fact the calling service is acting as a calling bridge= and
> =A0 =A0 capturing all the traffic. =A0While in theory i= t is possible to
> =A0 =A0 construct techniques which protect = against this form of attack, in
> =A0 =A0 practice these techniques all require far too much user i= ntervention
> =A0 =A0 to be practical, given the user interfac= e constraints described in
> =A0 =A0 [abarth-rtcweb].
>=A0
> =A0[BA] I think it's more than a user intervention/user inter= face issue.
> =A0Aside from snooping the signaling to see if t= he callee includes an
> =A0"isfocus" tag, how can th= e browser know if it is calling a conference
> =A0bridge or not? Personally, I'd remove the "in theory&= quot; sentence.

I rewrote to describe how this cou= ld in principle happen with
a fingerprint or an IdP.


> =A04.2.4. IP Location Privacy
= >=A0
> =A0 =A0 Note that as soon as the callee sends their = ICE candidates, the
> =A0 =A0 caller learns the callee's I= P addresses. =A0The callee's server
> =A0 =A0 reflexive address reveals a lot of information about the = callee's
> =A0 =A0 location. =A0In order to avoid tracking= , implementations may wish to
> =A0 =A0 suppress the start of = ICE negotiation until the callee has answered.
> =A0 =A0 In addition, either side may wish to hide their location = entirely by
> =A0 =A0 forcing all traffic through a TURN serve= r.
>=A0
> =A0[BA] Might be useful to say explicit= ly that the concern about location
> =A0privacy is restricted to media; hiding the client's locati= on from the Web
> =A0server is handled by things like ToR, and= signaling privacy is constrained
> =A0by the signaling protoc= ol (e.g. SIP privacy, etc.).

I added some material here.


> #11: Security vs. Security-Arch
= >=A0
> =A0At various points within the Security Architectur= e document, I had a
> =A0feeling of deju vu, encountering material that was also in the= Security
> =A0doc. =A0The overlap made me wonder if we should= either move some material
> =A0from Arch to Security, or whet= her we couldn't live with a single doc
> =A0instead of two.

I agree it's a bi= t awkward. I'm taking my guidance on one versus two
documents= from the chairs. If the WG wants me to merge, I'll do so.


> =A0Abstract
>=A0
= > =A0All but the last sentence of the abstract is identical to that of t= he
> =A0Security document. =A0Would it make some sense to shor= ten the abstract?
> =A0Also, references aren't allowed in abstracts.
Shortened it.


> =A0= Section 1
>=A0
> =A0The first paragraph duplicate= s material from the abstract as well as
> =A0Section 1 of the Security doc, and figure 1 is also included i= n both docs.
> =A0However, the security doc doesn't discus= s the multidomain case. =A0Would it
> =A0make sense to move ma= terial from Section 1 of this document to the
> =A0security doc? =A0If this were done, would we still need Sectio= n 1 in this
> =A0doc?

As long as thes= e are still separate documents, I'd like to keep this
one as-= is. I tried to keep the security document high-level, so I think
this is probably the right split...



> =A0Section 5.2
>=A0
> = =A0This section, with its requirements on APIs, seemed similar in spirit to=
> =A0Section 4.1 of the Security doc.

Agre= ed. The idea of Section 4.1 is to provide analysis and this to
pr= ovide nomative language. Agreed it's somewhat imperfect.


> =A0Section 5.4
>=A0
&= gt; =A0Material in this section (such as the discussion of ToR) seems like = it
> =A0might better belong in Section 4.2.4 of the Security d= oc.

I added some more high-level material into the security= doc.



> #10: Addi= tional Threats
>=A0
> =A0Aside from the threats d= escribed in the document, a few others come to
> =A0mind. =A0It might be useful for the document to state explicit= ly why or why
> =A0not these are out of scope:
>= =A0
> =A0a. Live versus replayed streams. =A0While you might h= ave media security,
> =A0this doesn't tell you whether the stream is actually origi= nating from a
> =A0device or is being replayed.
>= =A0
> =A0b. Prank calling. =A0While the document talks about p= ermission to make
> =A0calls, it doesn't mention permission to receive or blockin= g of unwanted
> =A0calls.

I added a s= ection about malicious peers.



DRAFT-IETF-RTCWEB-SECURITY-ARCH
----------------------------= ---
> WESTERLUND
> I have made an individual revi= ew of the security architecture document
> version 6 and have = the following comments.
>=A0
> 1. In title and in other places, should we use = WebRTC as the handle to
> the complete solution?
Done.


> 2. Section 7= .2 is wrongly labeled, I assume it is -04 version

Unfortunately not.

"Versi= on -04 was a version control mistake. =A0Please ignore."

> 3. Section 4:
> As is conventi= onal in the Web, all identities are
> =A0 =A0ultimately rooted that system.
>
&g= t; I guess this should be ... rooted in that system?

Fixed.


> 4. Figure 4. The arr= ow between Bob's browser and Bob's IdP is missalinged.

Fixed.

> 5. Section 4.1:
> Because this is an audio/video call, it creates
>= =A0 =A0two MediaStreams, one connected to an audio input and one connected=
> =A0 =A0to a video input.
>=A0
> I think= this normally would be one mediaStream but with two
> MediaSt= reamTracks.

Agreed.


<= /div>
> 6. Section 4.1:
> If Bob agrees [I am ignoring early= media for now], a PeerConnection
> =A0 =A0is instantiated wit= h the message from Alice's side.
>=A0
> I thi= nk you can remove the parenthesis. First of all I don't think it
> relavant in the paragraph. Secondly, early media doesn't exis= t in the
> context of a single peerConnection.

<= /div>
Removed.


> 7. Section = 4.3
>=A0
> If Alice and Bob authenticated via their IdPs,<= /div>
> =A0 =A0then they also know that the signaling service is not= mounting a man-
> =A0 =A0in-the-middle attack on theor traffi= c.
>=A0
> theor / their?

Fixed.<= /div>


> 8. Section 5.1:
>= =A0
> It is RECOMMENDED that browsers which allow
&g= t; =A0 =A0active mixed content nevertheless disable RTCWEB functionality in=
> =A0 =A0mixed content settings. [[ OPEN ISSUE: =A0Should this be a= 2119 MUST?
> =A0 =A0It's not clear what set of conditions= would make this OK, other than
> =A0 =A0that browser manufact= urers have traditionally been permissive here
> =A0 =A0here.]]
>=A0
> I am actually qui= te worried about not making this a MUST. Mixed content
> clear= ly causes significant security holes that I think really should be
> avoided.

Agreed. Changed per-wg discussion.


> 9. Section 5.1, similarly I thi= nk this applies to the second open issue
> in this section.

Changed. If people disagree, please objec.t
<= br>

> 10. Section 5.3:
>=A0
<= div>> [Note:
> =A0 =A0this document takes no position on th= e split between ICE in JS and
> =A0 =A0ICE in the browser. =A0The above text is written the way i= t is for
> =A0 =A0editorial convenience and will be modified a= ppropriately if the WG
> =A0 =A0decides on ICE in the JS.] =A0= The JS MUST NOT be permitted to control
> =A0 =A0the local ufrag and password, though it of course knows it= .
>=A0
> I think you can clean up this statement = as there is consensus to leave
> ICE in the browser.

Done.


> 11. Section 5= .3:
> A separate document will profile the ICE
> = =A0 =A0timers to be used; see [I-D.muthu-behave-consent-freshness].
>=A0
> We should clarify the WG consensus on this document = and the scope the
> document has.

I&#= 39;m not sure I understand this. Is this a proposed change to the
document or a WG action item?


> = 12. Section 5.4:
>=A0
> =A0 =A0API Requirement: = =A0The API MUST provide a mechanism for the calling
> =A0 =A0 = =A0 application JS to indicate that only TURN candidates are to be
> =A0 =A0 =A0 used. =A0This prevents the peer from learning one'= ;s IP address at
> =A0 =A0 =A0 all.
>=A0
> What about the ICE candidates related address information, that shou= ld
> be mentioned I think also as possible risk of leaking and what to set = it to.

Good point!


> 13. I am missing a discussion on how to avoid the linkage iss= ues. I
> think we need to point out the known sources to linkage that WebR= TC
> adds. I am aware of RTCP CNAMEs and as well as the certif= icate used in
> DTLS(-SRTP). Their should be recommendations o= n how to avoid these issues.

See S 5.5 below. Are you looking for something else.




> 14= . Section 5.5
> =A0 =A0[OPEN ISSUE: =A0What should the setting= s be here? =A0MUST?]
> =A0 =A0Implementations MAY support SDES for media traffic for bac= kward
> =A0 =A0compatibility purposes.
>=A0
=
> This needs to be resolved. I see no issues with retaining the
> possibility for SDES and other schemes. I think however, the downgrade=
> issues may need more discussion here. This is a somewhat di= scussed in
> the security considerations section later.

I plan to hold off on this till after the discussion in= Berlin.


> 15. Section 5.5
=
> =A0 =A0API Requirement: =A0The API MUST provide a mechanism to in= dicate that a
> =A0 =A0 =A0 fresh DTLS key pair is to be generated for a specific= call. =A0This
> =A0 =A0 =A0 is intended to allow for unlinkab= ility. =A0Note that there are also
> =A0 =A0 =A0 settings wher= e it is attractive to use the same keying material
> =A0 =A0 =A0 repeatedly, especially those with key continuity-base= d
> =A0 =A0 =A0 authentication.
>=A0
&g= t; I think this has to do with 13. For example should really the same
=
> certificate be used with different origins, unless it is a intent= ionally
> added endpoint certificate that provide verifiable source?
<= div>
No, it shouldn't be used with different origins exce= pt for thjat.


> 16. Section 5.5<= /div>
> [largely derived from
> =A0 =A0 =A0 [I-D.kaufman-rtc= web-security-ui]
>=A0
> Maybe this is more suitab= le in a contributors section instead of inline
> in text.

Done.


> 17. Secti= on 5.5:
>=A0
> =A0 =A0 =A0 * =A0The "securit= y characteristics" MUST indicate the cryptographic
> =A0 = =A0 =A0 =A0 =A0algorithms in use (For example: =A0"AES-CBC" or &q= uot;Null Cipher".)
>=A0
> Does there need to be additional discussion or = clarifications on high
> level indications when one uses NULL = cipher that doesn't provide
> confidentiality?

Good point. Added a new requirement here.


> 18. Section 5.6.2:
>=A0
&= gt; The details of the mechanism are described in the W3C API
> =A0 =A0specification,
>=A0
> I think a reference needs to be added here.
>=A0
> 19. Section 5.6.3
> Todo REF!

Added.


> = 20. Section 5.6.4.1:
>=A0
> =A0 =A0The "algorithm" and digest val= ues correspond directly to the
> =A0 =A0algorithm and digest i= n the a=3Dfingerprint line of the SDP.
>=A0
> Sho= uld there be a reference to where a=3Dfingerprint is defined here?

Done.


> Also= , does it need to be clarified what "algorithm" and digest
<= div>> reference, the ABNF contructs or value for those parameters.

I added "values" here. Is that what you were = looking for?


> 21. Section 5.6.4.2:
> This SDP attribute is und= erspecified. No clear definition of what is
> allowed, no IANA consideration section registering it.
=
It's just a base64-encoded identity attribute.


> Also, should this SDP attribute also ca= rry the origin of the IdP? I just
> wonder how a non browser can determine which IdP has been providi= ng the
> assertion.

It's in the a= ssertion. Do you think it would be better in the
a=3Dline?


> 22. Section 5.6.5.1 and following.<= /div>
>=A0
> I would like that all these JSON objects w= ould have a bit more crisp
> definitions. Sure, the JSON has c= ertain limiations in what values can be
> used, but it is unclear if the full UTF-8 values can be used in a= ll
> cases, or if there is restrictions on the URL provided, o= r if it should
> be URI's in fact?

OK. I will circle around with Ted (as a URL expert) and anyone else
who feels expert to try to nail this down.

> 23. I am missing a security discussion around the fact that I can cla= im
> to have an IdP and load whatever JS code into the proxy. What sec= urity
> implications deos this have. Section 5.6.5.2 does prov= ide some basic
> restrictions here. Are more needed?

I tried to hit this in 5.7.4. Generally if you are a si= te you can
always load new JS into the browser, so this is just p= art of the
threat model. Can you give me an example of what you&#= 39;re looking for.


> 24. Section 5.6.5.2.2:
&g= t;=A0
> =A0 =A0idp: =A0A dictionary containing the domain name= of the provider and the
> =A0 =A0 =A0 protocol string
>=A0
> What is the definition of dictionary here?

I'm not sure enough of the terminology here. Isn't dictionary
what we call JS associative-array type structures.



> 25. Are there any time limits= on responding to SIGN or Verify, or can
> you get application= s to hand simply by not responding to a IdP message?

I would hope the browser would produce an error at some point,
but I'm not sure we need to specify here.

<= br>
> 26. Section 5.6.5.2.3:
>=A0
> = Are the fields required to be included or not. This is a bit unclear.

Currently it says:

"MUST = contain a message field consisting of a dictionary/hash with the following = fields:"

Would you like it to say "which= MUST contain the following fields"



> Section 27. Section = 5.6.5.2.3:
> Open issue to resolve. Please try to resolve this= issue by talking to
> some people.

Agreed. This is now on my TODO list.


> 27. Section 5.6.5.2.3.1
>=A0
> Open issue = needing resolution. No opinion.

Will raise this in= Berlin.


> 28. Section 5.7.2:
>= =A0
> Missing the linkability issues discussion here.

Added some material.


> 29. Section 5.7.2:
>=A0
> Combined RTCWEB/To= r
> =A0 =A0implementations SHOULD arrange to route the media a= s well as the
> =A0 =A0signaling through Tor. [Currently this = will produce very suboptimal
> =A0 =A0performance.]

Done.

> I think you can remove the parenthis but ke= ep the text here.
>=A0
> 30. Page 40 SDP example = looks strange with no a=3Didenity attribute,
> instead just the JSON object.
Fixed.



OHLSSON
> When reading dr= aft-ietf-rtcweb-security-arch I noticed a couple of things that might be mi= ssing:
>=A0
> - According to section 4.3.2.4 in draft-ietf-rt= cweb-security there shold
> =A0 be a mechanism to verify that = the remote browser has engaged a "secure
> =A0 media mode= ". This mechanism is not (yet) described in the document.

Good catch. I have to write something here but I haven&= #39;t yet.


> - Except for paragr= aph 6 in section 4.1, there is not much said about
> =A0 the i= mplications of the "secure media mode".

This is referring to isolated streams, which is now in = gUM. How much
do you think I should say here?


> - An enterprise network with an HTTP proxy may no= t want external web sites to
> =A0 learn the IP addresses of its hosts using the PeerConnection = API. I'm
> =A0 not sure if this kind of attack is relevant= or not. If it is then
> =A0 it should be mentioned in Section= 5.4. IP Location Privacy.

Added some text.
o
> I also have= some minor comments on the rest of the document:
>=A0
> - Section 3, 1st paragraph
>=A0
> =A0 =A0= The basic assumption of this architecture is that network resources
> =A0 =A0exist in a hierarchy of trust, rooted in the browser, whic= h serves as
> =A0 =A0the user's TRUSTED COMPUTING BASE (TC= B).
>=A0
> =A0 The term "hierarchy of trust&= quot; is unclear in this context. Are there other
> =A0 nodes in this hierarchy except for the browser and web server= ?

I would claim browser, web server, idp (if any),= other network elements.



> - Section 3, 2nd paragraph
>=A0
> =A0 = =A0 This is a natural extension of the end-to-end principle.
>= =A0
> =A0 Perhaps it's just me but I don't understand = what this end-to-end principle is.

I just removed it since it doesn't add value.
=


> - Section 4.3, 1st paragraph
<= div>>=A0
> =A0 =A0 The total number of channels depends on = the amount of
> =A0 =A0 muxing; in the most likely case we are using both RTP/RTC= P mux and
> =A0 =A0 muxing multiple media streams on the same = channel, in which case
> =A0 =A0 there is only one DTLS handsh= ake.
>=A0
> =A0 =A0Won't there be separate handshake fo= r the data channel?

My understanding was that we c= ould mux the datachannel onto
the same 5-tuple.


> - Section 5.4, 1st paragraph
>=A0
> =A0 =A0 [...] which leaks large amounts of location information= ,
> =A0 =A0 especially for mobile devices.
>=A0
> =A0 =A0Why are mobile devices different in this aspect?

=
They're not. Removed.


> - Section 5.6.4
>=A0
> =A0 The SDP example= contains RTP/AVP but I thought SRTP was made mandatory?

Bit rot. Fixed.


> - Section 5.6.5.1, 3rd paragraph
>=A0
> =A0= =A0All requests from the PeerConnection object MUST contain an "id&qu= ot;
> =A0 =A0field which MUST be unique for that PeerConnection object.= =A0Any
> =A0 =A0responses from the IdP proxy MUST contain the= same id in response,
> =A0 =A0which allows the PeerConnection= to correlate requests and responses.
>=A0
> =A0 Couldn't the browser implementation han= dle the message routing
> =A0 without the id field?
=
This isn't about routing, it's about what happens if= there are
multiple outstanding queries.


= > - Section 5.6.5.1.1
>=A0
> =A0 The mandatory= id field is missing in the example

Fixed.


> - Section 5.6.5.2.2
>=A0
> =A0 How is the assertion field transformed into the a=3Didenti= ty attribute?
> =A0 I guess you=B4re using some form of B64 en= coding but this is not expained
> =A0 anywhere.

It's earlier, but I ad= ded it.


> - Section 5.6.5.2.3
>=A0
> =A0 I think the reason for including request= _origin should be explained here
> =A0 instead of in the end of the document.

I added a forward reference instead to avoid breaking up the document
flow.


> - Section 5.7.1,= 3rd paragraph
>=A0
> =A0 WebCrypto API lacks a reference.
= >=A0
> - Section 5.7.4.5.2
>=A0
>= =A0 =A0 Any IdP which uses cookies to persist logins will be broken
<= div>> =A0 =A0 by third-party cookie blocking.
>=A0
> =A0 Shouldn't it say "Any IdP which us= es third-party cookies"?

IdPs are inherently = third-party in this context.


> -= Appendix A and B
>=A0
> =A0 Both appendices appear unfinished. For exam= ple, ROAP is still mentioned
> =A0 in othe BrowserID example a= nd it's unclear what client credentials
> =A0 Bob uses in = the OAuth example.

Agreed. I have a TODO to clean these up.

=



JOHNSTON
= --------
> Again, lots of RTCWEB, RTCWeb, etc that should be W= ebRTC.

Fixed.


o> Th= e document introduction seems to be specific to audio and video
= =A0 WebRTC sessions. =A0Later, it becomes clear that the analysis applies
=A0 to the data channel as well. =A0This should be stated clearly up f= ront
=A0 and any differences between the two should be explained = (i.e. DTLS
=A0 vs SRTP encryption).

I ad= ded a sentence in S 4.3. This is actually the first significant
discussion of SRTP, so I think this works best.



> "SIP or XMPP" - XMPP isn= 9;t a signaling protocol but Jingle is, so that is probably what should be = mentioned, but Jingle doesn't use SDP.

I just left it as SIP.


> "Web sites whose origin we can verify (optimally via HTTP= S, but in some cases because we are on a topologically restricted network, = such as behind a firewall)" =A0- what is the 2nd case - no verificatio= n? =A0Verification using something other than HTTPS?

I added "and can infer authentication from firewal= l behavior"

> 3.1 =A0middle para graph is = basically saying that security policy can be applied after authentication -= might be worth stating this after the Dr. Evil analogy.

Added some text.

> 4. "= ;Specifically, Alice and Bob have relationships with
> =A0 =A0= some Identity Provider (IdP) that supports a protocol such as OpenID
> =A0 =A0or BrowserID) that can be used to demonstrate their identity to= other
> =A0 =A0parties." - needs one more ( to parse cor= rectly.
>=A0
> Figures 3 & 4. =A0Would be bet= ter to have IdP1 and IdP2 to make clear that this can be 2 different provid= ers. Also, Secure WebSockets should be shown with HTTPS. =A0=A0

Done.


> In F= igures 3 & 4, media is shown as DTLS-SRTP when the media is in fact SRT= P which is keyed with DTLS-SRTP. =A0In fact, RFC 3711 is not even reference= d, when it should be a normative reference, which is potentially very confu= sing and misleading for implementors. =A0There are many places where DTLS-S= RTP described as if it is more than a key agreement protocol for SRTP.

I changed this to be "DTLS+SRTP", added a ref= erence to RFC 3711, and
went through each use of DTLS-SRTP for ap= propriateness, modifying
where I thought necessary. Please let me= know if there are places I
missed.


> Figure 4 is the T= rapezoid of the overview and should be referenced as such.

Added a back reference to figure 2.

> JS is used but not defined. =A0

Defined it back in the intro.

=
> 4.1 =A0The first example in this document of microphone= and webcam permissions is that of a permanent grant. =A0Is this the model = we want to encourage? =A0Shouldn't the first mention be of the much saf= er per call grant? =A0Later the per call grant is mentioned, but deep in th= e document.

Rewritten.


>= 4.1 "This message is sent to the signaling server, e.g., by XMLHttpRe= quest[XmlHttpRequest] or by WebSockets [RFC6455] " =A0Sentence is miss= ing a period. =A0Do we really mean HTTPS and Secure WebSockets here?

I added "preferably over TLS".

=

> 4.1 "This allows the browser to display= a trusted element in the browser chrome indicating that a call is coming i= n from Alice." =A0Can this assertion be made now, prior to the DTLS-SR= TP handshake completing? =A0If this identity assertion is made at this stag= e, then a different fingerprint shows up in the DTLS-SRTP handshake, does t= he browser chrome then indicate 'sorry, I made a mistake, it isn't = Alice calling'?

I think at that point you just show a network error. Th= e identity
assertion indicates that Alice was trying to call and = if someone
is attacking, then that's just a failure.


> There are many cases of using [] in= stead of () for parentheical text.

I try to use []= for Notes or open issues.


> 4.2= ICE is not defined or referenced in its first occurance.

Fixed in 4.1.

> typo "= theor"
>=A0
> 5.1 "[[ OPEN ISSUE: =A0Sh= ould this be a 2119 MUST?
> =A0 =A0It's not clear what set= of conditions would make this OK, other than
> =A0 =A0that browser manufacturers have traditionally been permiss= ive here
> =A0 =A0here.]] "=A0
>=A0
> =A0 =A0[[ OPEN ISSUE:: =A0Should we be more aggressive about this?]]=
>=A0
> Do these issues need to be discussed in a W3C document where brow= ser expertise might help us do the right thing?

I = think we resolved this in Orlando and the document reflects what I think
the consensus was.


> 5.2 = =A0Do we really expect browsers to have X.509 certificates? =A0Does anyone = do this with DTLS-SRTP today? =A0Do browsers have UI to manage these certs?=

No, we don't. This was a request from Martin becaus= e he was expecting
servers might. I added some text to try to mak= e that clear.



> 5= .2 The API and UI requirements and elsewhere - should these be in a W3C doc= ument instead of/in addition to this document?

My sense is that IETF was responsible for the security = analysis so they
belong here.


=
> 5.2 "Implementations which support some form of direct user = authentication
> =A0 =A0SHOULD also provide a policy by which a user can authorize= calls only
> =A0 =A0to specific counterparties." =A0What= is a counterparty?

Changed to "communicating= peers."


> 5.3 =A0 ICE-Lite is not defined or = referenced. =A0Since this is a MUST, we need a normative reference - is it = what is described as ICE Lite in RFC 5245 or draft-rescorla-mmusic-ice-lite= ?

It's 5245 again. I added a cite.


> Question: =A0If a browser has multiple public/pr= ivate keys, including an X.509 one, can the JS suggest which one to use for= a particular PeerConnection?

I think the answer needs to be yes here, but we probabl= y need to clean
up the W3C API a bit to match.


> 5.5 Again, the media channel is secured using SR= TP, not DTLS-SRTP,
> which is one way to key SRTP. =A0In the future, new and better ke= y
> agreements will be developed, and if we write all our spec= s assuming
> one particular keying method, then they will beco= me obsolete.

Good point. Here is my new text which I hope is clearer= :

=A0 =A0Implementations MUST implement SRTP [RFC3= 711]. =A0Implementations MUST
=A0 =A0implement DTLS [RFC4347] and= DTLS-SRTP [RFC5763][RFC5764] for SRTP
=A0 =A0keying. =A0Implementations MUST implement
=A0 =A0[I-D= .ietf-tsvwg-sctp-dtls-encaps].

=A0 =A0All media ch= annels MUST be secured via SRTP. =A0Media traffic MUST NOT
=A0 = =A0be sent over plain (unencrypted) RTP. =A0DTLS-SRTP MUST be offered for
=A0 =A0every media channel and MUST be the default; i.e., if an
<= div>=A0 =A0implementation receives an offer for DTLS-SRTP and SDES, DTLS-SR= TP
=A0 =A0MUST be selected.

=A0 =A0All d= ata channels MUST be secured via DTLS.


> Section 5.6 with Appendix A reads l= ike a completely separate
> document. =A0It is also very hard = reading as there are lots of new
> concepts and ideas. =A0Shou= ld perhaps this be in a separate document?
> The basic security architecture for WebRTC is unlikely to change,=
> but given that we have no experience with this IdP system, = it seems
> likely that it will evolve and perhaps change signi= ficantly, which
> is an argument for a separate document.

= I agree the writing is a bit awkward. I'm rewriting App A to make it
clearer and I'll see what I can do to about making S 5.6 merge = better
as well.


> 5.6.4.2 =A0Is th= is document defining a new SDP attribute? =A0Shouldn't this be done in = MMUSIC?

I have a TODO here. Will consult with the = chairs.


> typos "implemementations"= =A0"termnating" "restrcitions"=A0

=
Fixed.


> WebIntents mention= ed without reference or explanation.

WebIntents is OBE. Removed.

> Missing normative reference: RFC 3711.

Fixed.


-Ekr




--047d7b6da78246f54a04e18ce9ab-- From bo.burman@ericsson.com Mon Jul 15 08:15:26 2013 Return-Path: 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 BB6A221E8088 for ; Mon, 15 Jul 2013 08:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.032 X-Spam-Level: X-Spam-Status: No, score=-4.032 tagged_above=-999 required=5 tests=[AWL=2.217, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 TcM-SBqeXhAO for ; Mon, 15 Jul 2013 08:15:22 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED6E21E804D for ; Mon, 15 Jul 2013 08:15:21 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-67-51e41208d836 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CD.6F.19388.80214E15; Mon, 15 Jul 2013 17:15:20 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.188]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Mon, 15 Jul 2013 17:15:19 +0200 From: Bo Burman To: "rtcweb@ietf.org" Thread-Topic: Some thoughts on optional audio codecs Thread-Index: Ac6BN11IugiIgzm2TXug3PomYB8N3A== Date: Mon, 15 Jul 2013 15:15:19 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+JvrS6H0JNAgzcHNC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoqj19gLpkhUvG09wtzAeFm4i5GDQ0LARGLabtYuRk4gU0zi wr31bF2MXBxCAocZJWaf2s4E4SxhlLh9bwITSBWbgIbE/B13GUFsEQF1icsPL7CD2MIC+hKP Lsxkg4ibSByb8BvK1pO4dWs62AYWAVWJC7evgsV5BXwljnVuYwGxGQVkJe5/vwdmMwuIS9x6 Mp8J4iIBiSV7zjND2KISLx//Y4U4WlFieb8cRLmexI2pU9ggbG2JZQtfM0OMF5Q4OfMJywRG 4VlIps5C0jILScssJC0LGFlWMbLnJmbmpJebb2IEBvHBLb8NdjBuui92iFGag0VJnHez3plA IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwLvV9+mvmt5fjzF0WJF1+1Zp7OObg2+Wr8/Hff GB7cTvqVM+ns9MNfDpX9miH5s/tke9HJrPzPS2d8LVRmtL5qf+v1pjsyOru8tyXOf6SZJdB6 yTtvPaPi9z1zRXYHv61c9uj/9hX3PlQzWzxf/+CDdFZwd1bq2xe7/qbscOTar6cbZDyj9v8P GSWW4oxEQy3mouJEAGQIMrMwAgAA Subject: [rtcweb] Some thoughts on optional audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:15:26 -0000 Regarding the previous discussion on optional audio codecs in the (currentl= y expired) draft on RTCWEB audio codecs (https://datatracker.ietf.org/doc/d= raft-ietf-rtcweb-audio/): I think most parties involved in WebRTC work, myself included, hope and bel= ieve that it will be ubiquitous and easy to include real-time media convers= ation functionality in nearly any web context. Since it will be that easy, = it can be expected that most web developers need not be, and thus will not = be, media specialists or very knowledgeable about codecs. The definition of RTCWEB MTI codecs ensures that communication is possible = since at least one codec will always be found, but it is not possible to cl= aim the resulting communication to be optimum for every possible context. Even if WebRTC will be close to ubiquitous, there will for quite some time = likely be a desire to reach real-time media domains and devices that were n= ot originally designed for and thus are not optimized for use with WebRTC. = A communication device that is not designed solely for WebRTC use will like= ly include functionality and codecs also for its "native" domain. Any added cost of not being able to use existing "native" codecs will vary = both in amount and where the cost has to be taken. Eliminating it is indeed= an optimization, but the total cost savings may still be significant. With the current design and to my understanding, it will be the browser ven= dor's choice to add optional codecs, including any "native" domain codecs. = The choice may possibly be delegated to individual web developers making u= se of WebRTC functionality. A browser vendor will arguably have to know eac= h target platform to some extent, but it can hardly be assumed that a web d= eveloper knows the capabilities of all devices that will use the WebRTC-ena= bled site unless the browser can provide the needed information. There is a= risk that "native" codecs in devices are not well handled, unless the moti= vations and methods to make use of them are better specified. While any audio codecs besides the MTI ones are clearly optional, I believe= the suggested text addition on optional audio codecs to the RTCWEB audio d= raft in Ticket #12 (http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12#) t= o be too brief considering the above. In that draft, I would prefer something more in line with: "If other suitable audio codecs are available to the browser to use, it is = recommended that they are also included in the offer in order to maximize t= he possibility to establish the session without the need for audio transcod= ing". Assuming that the browser vendor (or web developer) is sufficiently concern= ed with codecs to read the audio codecs draft (or the corresponding RFC to-= be), the above text may, as a start, give some added guidance why non-MTI c= odecs may be desirable to consider in addition to the MTI ones. Cheers, Bo Multimedia Technologies Ericsson Research F=E4r=F6gatan 6 SE-164 80, Kista, Sweden www.ericsson.com From suhasietf@gmail.com Mon Jul 15 08:43:34 2013 Return-Path: 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 EA3AB11E8138 for ; Mon, 15 Jul 2013 08:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WB4BWa4JqNJC for ; Mon, 15 Jul 2013 08:43:31 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 53F6D11E80EA for ; Mon, 15 Jul 2013 08:43:27 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so10235719wev.16 for ; Mon, 15 Jul 2013 08:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yc28imxP6VTQte8cinccqnRSFPCxpgu+bUtVutqbfnM=; b=pVunyt8Or74WQQakb5wIw7SOBIJ4dvIfJy6xro0ups+5p0xGJ4TsTjU5qtOnXrYEwl h1+yey64ecd2bVvtl+bT47J3byiZwBidJ1ttUE1Ds3VUPmOYmDPcH4OFyoUeA4kUC2+i cL2LyNS7yNd1UpYkiS59/azJtnqJnLkMMZXosYZHm8GfUGG/REYpNSlcZhyrOM6mktfA jmsmjIcph27NWnsqb+xUOPk1axaI4uuxrLFdX/QEJe6zBMiH53yWHliTAiVKII9VKtb0 7hW3gb8SBu5rnZJfWmWo7FdYGU5x0xw8Fa0mSByfPqwPHnaCWuXoAjlLBeWRfwpiZ5yW v9Tg== MIME-Version: 1.0 X-Received: by 10.180.212.70 with SMTP id ni6mr5806510wic.11.1373903006492; Mon, 15 Jul 2013 08:43:26 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Mon, 15 Jul 2013 08:43:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 08:43:26 -0700 Message-ID: From: Suhas Nandakumar To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=001a11c3505ea86bbb04e18eb8be Subject: [rtcweb] FW: New Version Notification for draft-nandakumar-mmusic-sdp-mux-attributes-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:43:34 -0000 --001a11c3505ea86bbb04e18eb8be Content-Type: text/plain; charset=ISO-8859-1 Hello All An updated version of the SDP Attributes Mux draft has been submitted with reviews for close to 50% of the attributes completed. Thanks every one for their valuable inputs. We are half-way there :) Cheers Suhas Nandakumar A new version of I-D, draft-nandakumar-mmusic-sdp-mux-attributes-03.txt has been successfully submitted by Suhas Nandakumar and posted to the IETF repository. Filename: draft-nandakumar-mmusic-sdp-mux-attributes Revision: 03 Title: A Framework for SDP Attributes when Multiplexing Creation date: 2013-07-15 Group: Individual Submission Number of pages: 56 URL: http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-sdp-mux-attributes-03.txt Status: http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-sdp-mux-attributes Htmlized: http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-nandakumar-mmusic-sdp-mux-attributes-03 Abstract: The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. In the RTCWeb WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Sessions multiplexed over a single transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. The specification also categorizes existing attributes based on the framework described herein. --001a11c3505ea86bbb04e18eb8be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All

=A0 =A0An updat= ed version of the SDP Attributes Mux draft has been submitted with reviews = for close to 50% of the attributes completed. Thanks every one for their va= luable inputs. We are half-way there :)


Cheers
Suhas Nandakumar
<= div>
A new version of I-D, draft-nandakumar-mmusic-sdp-mux-at= tributes-03.txt
has been successfully submitted by Suhas Nandakum= ar and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0dra= ft-nandakumar-mmusic-sdp-mux-attributes
Revision: =A0 =A0 =A0 =A0= 03
Title: =A0 =A0 =A0 =A0 =A0 A Framework for SDP Attributes when= Multiplexing
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individu= al Submission
Number of pages: 56
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-nandakumar-mmusic-sdp-mux-attributes-03

Abstract:
=A0 =A0The Session Description Protocol (SDP) provides mechanisms to
=A0 =A0describe attributes of multimedia sessions and of individua= l media
=A0 =A0streams (e.g., Real-time Transport Protocol (RTP) = sessions) within a
=A0 =A0multimedia session. =A0In the RTCWeb WG, there is a need to use= a
=A0 =A0single 5-tuple for sending and receiving media associat= ed with
=A0 =A0multiple media descriptions ("m=3D" line= s). =A0Such a requirement has
=A0 =A0raised concerns over the semantic implications of the SDP attri= butes
=A0 =A0associated with the RTP Sessions multiplexed over a = single transport
=A0 =A0layer flow.

=A0 = =A0The scope of this specification is to provide a framework for
=A0 =A0analyzing the multiplexing characteristics of SDP attributes. = =A0The
=A0 =A0specification also categorizes existing attributes = based on the
=A0 =A0framework described herein.

--001a11c3505ea86bbb04e18eb8be-- From carlberg@g11.org.uk Thu Jul 11 09:05:32 2013 Return-Path: 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 2A01921F9C6D; Thu, 11 Jul 2013 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Pqbv-+O-XZ3S; Thu, 11 Jul 2013 09:05:27 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2916621F9F4C; Thu, 11 Jul 2013 09:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=zZNnM09X3aVQDZwGbcmvuadW1XS1GoF3JpGeUovatK8=; b=h23GCqdPprhQ2OoEgPk6Uiego+EIVZUlpBS/FeyIE/NGNsSe64wCjQRNZgczw5Y3oWqJi8/3jgWMR1XX1qG2llpWqwm5zRlOwOqOr1lT7s9Eaz6qzfK1F0cD7dNIddpq; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:37990 helo=[10.0.1.20]) by portland.eukhosting.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UxJMZ-003R6H-4J; Thu, 11 Jul 2013 17:04:59 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: ken carlberg In-Reply-To: <20130710180147.GA614@cisco.com> Date: Thu, 11 Jul 2013 12:04:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> References: <20130710180147.GA614@cisco.com> To: Toerless Eckert (eckert) X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Mon, 15 Jul 2013 08:47:47 -0700 Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:05:32 -0000 Toerless, some food for thought... about 10 years ago, I put together a draft that added an optional TLV = prioritization header to RTP to accomplish something similar in terms of = having the app decide which was the better RTP packet to drop during = times of congestion. My aim was to have these decisions made at = forwarding application-layer gateways that did not act as a RTP/RTCP = endpoint. The strength of the approach (in my opinion :-) was that it = could span pockets of non-diff-serv regions and still carry significance = downstream. The weakness was the need for DPI if one wanted to make a = more informed decision along the path about dropping a packet. I wonder if such a dual-layer design might be helpful in your efforts. = In any case, I have an interest in the normalizer draft. -ken On Jul 10, 2013, at 2:01 PM, Toerless Eckert (eckert) = wrote: > When dealing with congestion for real-time datagram (UDP/RTP) based = video flows, one idea > that we think has shown to provide good value is to intelligently drop = in the network > preferentially the least important packets within a video flow, for = example non-referenced > P-frames, because their loss creates the lowest impact to video = quality. >=20 > One of the main concerns raised against such schemes was one of = fairness. If flows=20 > would start to indicate different priorities for packets in them, how = would we > be able to avoid that flows would indicate all their packets to be of = high priority > to shift packet drops to other flows. Or even more importantly: how = could we motivate > flows to indicate that some of their packets are low priority without = them having to > fear that they would experience more loss than than flows that don't = do this. >=20 > So, there is one draft that we would like to present (presumably in = TSVWG) explaining > how we think this problem can be solved: = draft-lai-tsvwg-normalizer-00.txt >=20 > (Actually, this is how we did solve the problem in our implementatin = of intelligent dropping, > so this is not theoretical). >=20 > Now granted, the problem of fairness is but one element of building a = complete ssytem > around the idea of intelligent dropping, so if folks here on the lists = would like to > see for example=20 >=20 > a) how well can it work in routers to shift packet drops to low-prio = packets > b) whats the evidence that it's good for video quality > c) How should we do the marking best going forward >=20 > Then please let us know. We'd be very interested to provide insight = into the parts of > those pieces that we have also worked out or discuss the ones we have = not (primarily c ;-) >=20 > Thanks! > Toerless >=20 > In-Reply-To: = >=20 > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) = wrote: >> Hi all, >>=20 >> We have submitted a new Internet draft to describe a Normalization = Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The = goal of NM deployment is to create a new incentive for video encoders to = generate more discardable packets when using AF PHB in DIffServ. We are = looking forward to your review comments. >>=20 >> Best regards, >> CJ >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: Friday, February 08, 2013 6:25 PM >> To: Cheng-Jia Lai (chelai) >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert = (eckert); Fred Yip (fyip) >> Subject: New Version Notification for = draft-lai-tsvwg-normalizer-00.txt >>=20 >>=20 >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >> has been successfully submitted by Cheng-Jia Lai and posted to the >> IETF repository. >>=20 >> Filename: draft-lai-tsvwg-normalizer >> Revision: 00 >> Title: Normalization Marker for AF PHB Group in = DiffServ >> Creation date: 2013-02-08 >> WG ID: Individual Submission >> Number of pages: 15 >> URL: = http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer >> Htmlized: = http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 >>=20 >>=20 >> Abstract: >> This memo describes a Normalization Marker (NM) at DiffServ (DS) >> nodes to normalize the distribution of DS codepoint (DSCP) markings >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is >> useful for traffic conditioning with Active Queue Management (AQM) >> when the AF PHB group is deployed for multimedia service classes = that >> carry video packets with advanced codec technologies. Using NM can >> offer an incentive that is however missing in today's ecosystem of >> practical deployment, i.e., when congestion occurs in the AF PHB >> group, the network should allow a video codec to benefit from its >> effort of generating finer layers of intra-flow precedence (IFP) = with >> discardable packets in a more balanced distribution. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 From carlberg@g11.org.uk Mon Jul 15 06:41:33 2013 Return-Path: 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 3C2DE11E810C; Mon, 15 Jul 2013 06:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 dhU2PQNhCNM8; Mon, 15 Jul 2013 06:41:28 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 713C211E8106; Mon, 15 Jul 2013 06:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=4uuGNwkwMEtRoU89d14nNhxJ8Zr7/VugapQ4pVe98/Q=; b=ajERd2nXYuBq0jMBWcrFqmvIIDkXd8iTHgV4mWXIzctLfRARsVUJo6ZH5rqdsQl4ailMGFE8wfc5JjbtnRFNav4oJrr+ouwUowdUBMeCJwJFHb7Ml2HrxrUo/E9cU0+x; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:47783 helo=[10.0.1.20]) by portland.eukhosting.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uyj1l-002GU4-0e; Mon, 15 Jul 2013 14:41:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: ken carlberg In-Reply-To: <20130712003002.GA30036@cisco.com> Date: Mon, 15 Jul 2013 09:41:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6D6A9A05-73A6-400A-831D-F4BF14AFAFD0@g11.org.uk> References: <20130710180147.GA614@cisco.com> <34BE8BE0-E863-4F69-8D45-18F5B97DE392@g11.org.uk> <20130712003002.GA30036@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Mon, 15 Jul 2013 08:47:47 -0700 Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [rmcat] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:41:33 -0000 Toerless, sorry for the tardy reply. I'll dig through my archives and send you a = copy. my draft proposed adding a "classifier" field, but I only did one = rev (which was missing some better rationale after a long talk I had = with Dave Oran) and i suspect that it would need a fair amount of = scrubbing before re-issuing another version. the first order of = business, though, will be to gauge the feedback/comments to your draft. -ken ps, CJ thanks for your clarification in your previous response On Jul 11, 2013, at 8:30 PM, Toerless Eckert wrote: > Thanks, Ken >=20 > Indeed yes, that's exactly the line of thought that we would like to > see proceed as well. Any URL still existing for that draft ? >=20 > "application layer gateway" could specifically mean switching MCU = using > intelligent dropping in conjunction with outbound congestion control. >=20 > I definitely would like to see RTP headers as the ultimatele marking > option even for routers to do intelligent dropping (or other packet > processing "beyond DSCP)). Intra-flow (per-packet) DSCP is just a big = pain=20 > (aka: impossible) for applications. Many OSs don't have any APIs to = support > this. And DSCP management in networks is already difficult enough as = it > stands. >=20 > Would certainly like to see if there is interest to write up r present > more pieces of this puzzle, especially an RTP extension. We just felt = that the > fairness in intelligent dropping was the biggest concern our video > application folks had, that's why we wanted to explain how that piece > could work first.=20 >=20 > Cheers > Toerless >=20 >=20 > On Thu, Jul 11, 2013 at 12:04:58PM -0400, ken carlberg wrote: >> Toerless, >>=20 >> some food for thought... >>=20 >> about 10 years ago, I put together a draft that added an optional TLV = prioritization header to RTP to accomplish something similar in terms of = having the app decide which was the better RTP packet to drop during = times of congestion. My aim was to have these decisions made at = forwarding application-layer gateways that did not act as a RTP/RTCP = endpoint. The strength of the approach (in my opinion :-) was that it = could span pockets of non-diff-serv regions and still carry significance = downstream. The weakness was the need for DPI if one wanted to make a = more informed decision along the path about dropping a packet. >>=20 >> I wonder if such a dual-layer design might be helpful in your = efforts. In any case, I have an interest in the normalizer draft. >>=20 >> -ken >>=20 >>=20 >> On Jul 10, 2013, at 2:01 PM, Toerless Eckert (eckert) = wrote: >>=20 >>> When dealing with congestion for real-time datagram (UDP/RTP) based = video flows, one idea >>> that we think has shown to provide good value is to intelligently = drop in the network >>> preferentially the least important packets within a video flow, for = example non-referenced >>> P-frames, because their loss creates the lowest impact to video = quality. >>>=20 >>> One of the main concerns raised against such schemes was one of = fairness. If flows=20 >>> would start to indicate different priorities for packets in them, = how would we >>> be able to avoid that flows would indicate all their packets to be = of high priority >>> to shift packet drops to other flows. Or even more importantly: how = could we motivate >>> flows to indicate that some of their packets are low priority = without them having to >>> fear that they would experience more loss than than flows that don't = do this. >>>=20 >>> So, there is one draft that we would like to present (presumably in = TSVWG) explaining >>> how we think this problem can be solved: = draft-lai-tsvwg-normalizer-00.txt >>>=20 >>> (Actually, this is how we did solve the problem in our implementatin = of intelligent dropping, >>> so this is not theoretical). >>>=20 >>> Now granted, the problem of fairness is but one element of building = a complete ssytem >>> around the idea of intelligent dropping, so if folks here on the = lists would like to >>> see for example=20 >>>=20 >>> a) how well can it work in routers to shift packet drops to low-prio = packets >>> b) whats the evidence that it's good for video quality >>> c) How should we do the marking best going forward >>>=20 >>> Then please let us know. We'd be very interested to provide insight = into the parts of >>> those pieces that we have also worked out or discuss the ones we = have not (primarily c ;-) >>>=20 >>> Thanks! >>> Toerless >>>=20 >>> In-Reply-To: = >>>=20 >>> On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) = wrote: >>>> Hi all, >>>>=20 >>>> We have submitted a new Internet draft to describe a Normalization = Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The = goal of NM deployment is to create a new incentive for video encoders to = generate more discardable packets when using AF PHB in DIffServ. We are = looking forward to your review comments. >>>>=20 >>>> Best regards, >>>> CJ >>>>=20 >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >>>> Sent: Friday, February 08, 2013 6:25 PM >>>> To: Cheng-Jia Lai (chelai) >>>> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert = (eckert); Fred Yip (fyip) >>>> Subject: New Version Notification for = draft-lai-tsvwg-normalizer-00.txt >>>>=20 >>>>=20 >>>> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt >>>> has been successfully submitted by Cheng-Jia Lai and posted to the >>>> IETF repository. >>>>=20 >>>> Filename: draft-lai-tsvwg-normalizer >>>> Revision: 00 >>>> Title: Normalization Marker for AF PHB Group in = DiffServ >>>> Creation date: 2013-02-08 >>>> WG ID: Individual Submission >>>> Number of pages: 15 >>>> URL: = http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer >>>> Htmlized: = http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> This memo describes a Normalization Marker (NM) at DiffServ (DS) >>>> nodes to normalize the distribution of DS codepoint (DSCP) = markings >>>> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM = is >>>> useful for traffic conditioning with Active Queue Management (AQM) >>>> when the AF PHB group is deployed for multimedia service classes = that >>>> carry video packets with advanced codec technologies. Using NM = can >>>> offer an incentive that is however missing in today's ecosystem of >>>> practical deployment, i.e., when congestion occurs in the AF PHB >>>> group, the network should allow a video codec to benefit from its >>>> effort of generating finer layers of intra-flow precedence (IFP) = with >>>> discardable packets in a more balanced distribution. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>> --=20 >>> --- >>> Toerless Eckert, eckert@cisco.com >>> Cisco NSSTG Systems & Technology Architecture >>> SDN: Let me play with the network, mommy! >>>=20 >>=20 >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 From suhasietf@gmail.com Mon Jul 15 10:18:28 2013 Return-Path: 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 848EF21E8117; Mon, 15 Jul 2013 10:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 ASGiqPhzepiM; Mon, 15 Jul 2013 10:18:27 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 49BDF21E8106; Mon, 15 Jul 2013 10:18:27 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so3156686wiw.5 for ; Mon, 15 Jul 2013 10:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FzsSFcHGHcH6qb5qhhbfkBc565YDfEH38x7wjsK0o2g=; b=QtrqWF4W8ST/smdFWXSFAmbmSwTwPbB3LasHxcAcWpd9krmVbdKaTCuSWE+Bjh9sxP lCqN+1oE3vnUeuGi8Bvc3dVd74USkqiYqQXRE+qQFX3nd9zyXvi5gKd0qDbcppleLdVs /OMJykcgh6LcmF8zlgQ4/WejgcVDfIA3JLz/hHtYEaEi09v50daecA4F/D5vM4gytBm8 SAzfnsWukKFH7dKRLJCSFwBDFkUDlGrGBSfp0jQKazqJUHO7XkBfd5TJtiGZ0fa+/+wl WLPWiv7mXZpk2Xq290R6CgDOQL0hTHL/7iiLm3Hcrm/KR5e3Lg9hPIVVcff3PJOtQ/XQ 07CQ== MIME-Version: 1.0 X-Received: by 10.194.179.33 with SMTP id dd1mr32143166wjc.51.1373908706411; Mon, 15 Jul 2013 10:18:26 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Mon, 15 Jul 2013 10:18:26 -0700 (PDT) Date: Mon, 15 Jul 2013 10:18:26 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=089e013d0f806648e504e1900c34 Subject: [rtcweb] New Draft: draft-nandakumar-mmusic-rtcweb-grouping-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:18:28 -0000 --089e013d0f806648e504e1900c34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All A new draft has been submitted to describe Simulcast streams within SDP based on RFC5576 ssrc-grouping semantics. Please have a read and let me know your thoughts Cheers Suhas A new version of I-D, draft-nandakumar-mmusic-rtcweb-grouping-00.txt has been successfully submitted by Suhas Nandakumar and posted to the IETF repository. Filename: draft-nandakumar-mmusic-rtcweb-grouping Revision: 00 Title: SSRC Group Based Simulcast Signaling Creation date: 2013-07-15 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-grouping= -00.txt Status: http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-grouping Htmlized: http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00 Abstract: In some applications it may be necessary to send multiple media encodings corresponding to a media source with in independent RTP media streams. This is called Simulcast. This document discusses a framework for describing simulcast media streams in SDP and also defines semantics to express relationship amongst them. The semantics defined in this document are to be used with the source specific grouping framework defined in the [RFC5576] --089e013d0f806648e504e1900c34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All<= /div>

<= /div>
=A0 =A0A new= draft has been submitted to describe Simulcast streams within SDP based on= RFC5576 ssrc-grouping semantics.

=
Please have a rea= d and let me know your thoughts

Chee= rs
Su= has
<= span style=3D"font-family:monospace;font-size:16px">
A new version of I-D, draft-nandakumar-mmusic-rtcweb-grouping-= 00.txt
has been successfully submitted b= y Suhas Nandakumar and posted to the
IETF repository.

Filename:=A0=A0=A0=A0=A0=A0=A0 draft-nandakumar-mmusic-rtcweb-groupin= g
Revision:=A0=A0=A0=A0= =A0=A0=A0 00
Title:=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 SSRC Group Based Simulcast Signaling
Creation date:=A0=A0 2= 013-07-15
Group:=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Individual Submission
Number of pages: 8
URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-gr= ouping-00.txt
Status:=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-gr= ouping
Htmlized:=A0=A0=A0=A0= =A0=A0=A0=A0http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00<= /a>


Abstract:
=A0=A0 In some applicatio= ns it may be necessary to send multiple media
=A0=A0 encodings corre= sponding to a media source with in independent RTP
=A0=A0 media streams.=A0 This is called Simulcast.=A0 This docum= ent discusses a
=A0=A0 framework for d= escribing simulcast media streams in SDP and also
=A0=A0 defines semantics to express relationship amongst them.=A0= The
=A0=A0 semantics defin= ed in this document are to be used with the source
=A0=A0 specific grouping framework defined in the [RFC5576] --089e013d0f806648e504e1900c34-- From suhasietf@gmail.com Mon Jul 15 11:34:49 2013 Return-Path: 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 3549121F8529; Mon, 15 Jul 2013 11:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YTj40v21ItiB; Mon, 15 Jul 2013 11:34:48 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D30BD11E8153; Mon, 15 Jul 2013 11:34:47 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so3237299wiv.1 for ; Mon, 15 Jul 2013 11:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=FNrt7v4qeL0HFFrF8RVaB0F2sOaIRHrSAa0ZL+1jufg=; b=MG4665NqlLtarxNFxLrCjZABlNVa8al+8neGZf8/hNbHC5WpAPXgpQWxc0KtvgJVsX a0EqhyPPLLsyystCUcpkWfrFEL1zypjRJRL7GC7z8ynQ7+Wk84fWtHrDD6j+L6kjd17a 0E5aREwp0237BqnNAy1gic+uwKUAfipJmC/KiVCvL7r/Yr0en/VINM8F/GBLwRD9ol8t +EhSrQ9rDzi8YRDGF25UiKMyoviydNfr9UTiiNsDnHvL69ApOPQoyAOaeYvGhsGvl8iQ 9PrQcBySdMy7D2awdqHbvzuNgzFIUx2PCu7rtRFHgldRhO+Eu59TaR/cjJuBXMyY3Z35 6MQA== MIME-Version: 1.0 X-Received: by 10.194.109.104 with SMTP id hr8mr32505089wjb.32.1373913286915; Mon, 15 Jul 2013 11:34:46 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Mon, 15 Jul 2013 11:34:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 11:34:46 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7bf10aea6b3ecd04e1911dd1 Subject: Re: [rtcweb] New Draft: draft-nandakumar-mmusic-rtcweb-grouping-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:34:49 -0000 --047d7bf10aea6b3ecd04e1911dd1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The links in my earlier email seems to have mail.cisco.com redirects and hence I am including the direct links for the same below Filename: draft-nandakumar-mmusic-rtcweb-grouping Revision: 00 Title: SSRC Group Based Simulcast Signaling Creation date: 2013-07-15 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-grouping= -00.txt Status: http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-grouping Htmlized: http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00 Sorry for the inconvenience Cheers Suhas PS: Thanks Martin and Ethan for catching this. On Mon, Jul 15, 2013 at 10:18 AM, Suhas Nandakumar wro= te: > Hello All > > A new draft has been submitted to describe Simulcast streams within SD= P > based on RFC5576 ssrc-grouping semantics. > > Please have a read and let me know your thoughts > > Cheers > Suhas > > A new version of I-D, draft-nandakumar-mmusic-rtcweb-grouping-00.txt > has been successfully submitted by Suhas Nandakumar and posted to the > IETF repository. > > Filename: draft-nandakumar-mmusic-rtcweb-grouping > Revision: 00 > Title: SSRC Group Based Simulcast Signaling > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-groupi= ng-00.txt > Status: > http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-grouping > Htmlized: > http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00 > > > Abstract: > In some applications it may be necessary to send multiple media > encodings corresponding to a media source with in independent RTP > media streams. This is called Simulcast. This document discusses a > framework for describing simulcast media streams in SDP and also > defines semantics to express relationship amongst them. The > semantics defined in this document are to be used with the source > specific grouping framework defined in the [RFC5576] --047d7bf10aea6b3ecd04e1911dd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


The links in my earlier email seems to have <= a href=3D"http://mail.cisco.com" target=3D"_blank">mail.cisco.com redir= ects and hence I am including the direct links for the same below

<= /div>
Filename: =A0 =A0 =A0 =A0draft-= nandakumar-mmusic-rtcweb-grou= ping
Revision: =A0 =A0 =A0 =A0 00<= br style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px= ;background-color:rgb(255,255,255)"> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0SS= RC Group Based Simulcast Signaling
Creation date: =A0=A02013-07-15
Group: =A0 =A0 =A0 =A0 =A0 =A0Indivi= dual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0=A0h= ttp://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-grouping-= 00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatrack= er.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-grouping
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.or= g/html/draft-nandakumar-mmusic-rtcweb-grouping-00

Sorry for the inconvenience

Ch= eers
Suhas
PS: Thanks Martin and Ethan for catching this.


On Mon, Jul 15, 2013 at= 10:18 AM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
Hello All

=A0 = =A0A new draft has been submitted to describe Simulcast streams within SDP = based on RFC5576 ssrc-grouping semantics.

=
Please have a rea= d and let me know your thoughts

Chee= rs
Su= has
<= span style=3D"font-family:monospace;font-size:16px">
A new version of I-D, draft-nandakumar-mmusic-rtcweb-grouping-= 00.txt
has been successfully submitted b= y Suhas Nandakumar and posted to the
IETF repository.

Filename:=A0=A0=A0=A0=A0=A0=A0 draft-nandakumar-mmusic-rtcweb-groupin= g
Revision:=A0=A0=A0=A0= =A0=A0=A0 00
Title:=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 SSRC Group Based Simulcast Signaling
Creation date:=A0=A0 2= 013-07-15
Group:=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Individual Submission
Number of pages: 8
URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= http://www.ietf.org/internet-drafts/draft-nandakumar-mmusic-rtcweb-gr= ouping-00.txt
Status:=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-rtcweb-= grouping
Htmlized:=A0=A0=A0=A0= =A0=A0=A0=A0http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00<= /a>


Abstract:
=A0=A0 In some applicatio= ns it may be necessary to send multiple media
=A0=A0 encodings corre= sponding to a media source with in independent RTP
=A0=A0 media streams.=A0 This is called Simulcast.=A0 This docum= ent discusses a
=A0=A0 framework for d= escribing simulcast media streams in SDP and also
=A0=A0 defines semantics to express relationship amongst them.=A0= The
=A0=A0 semantics defin= ed in this document are to be used with the source
=A0=A0 specific grouping framework defined in the [RFC5576]

--047d7bf10aea6b3ecd04e1911dd1-- From mperumal@cisco.com Mon Jul 15 11:45:07 2013 Return-Path: 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 B9FF511E81E3 for ; Mon, 15 Jul 2013 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 kUjexLxuA4Ha for ; Mon, 15 Jul 2013 11:45:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BAD6811E81CE for ; Mon, 15 Jul 2013 11:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2299; q=dns/txt; s=iport; t=1373913902; x=1375123502; h=from:to:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=bC8A7L871Vc4dslEbNqw4z7GZFkrPI9EzaLfSwLQn+w=; b=bAFn3wK19ITMZuQu3CvnA1C4spFHqt87LVBR+W4QUvwG9+Y3Cr6T8GQB pKteRj/oXtCL+eoENENcRIHbreKOWUbjTXUmZ+uiZxRNgUB3kF8+h2PJx DkxRZy/RBl7D02I32E8yqdmrY88/0OBAoPDGpfcv3UktJz6XFoftNZJ/j Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FABxC5FGtJXG+/2dsb2JhbABagwY0SQbBUoETFnSCIwEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQHAQEFAwIEEwgBiAcHBbVzjzMzC4MFbQOZBYsBhSODEoIo X-IronPort-AV: E=Sophos;i="4.89,670,1367971200"; d="scan'208";a="235091247" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 15 Jul 2013 18:44:52 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6FIipXb013777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Jul 2013 18:44:51 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 13:44:51 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgYIhJ+v92XkONkuATNVM7xrPPZlmEicggAABR8A= Date: Mon, 15 Jul 2013 18:44:51 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.56.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:45:07 -0000 Forwarding it to rtcweb.. -----Original Message----- From: Muthu Arul Mozhi Perumal (mperumal)=20 Sent: Tuesday, July 16, 2013 12:13 AM To: behave@ietf.org Subject: FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt The text and the algorithm in the draft are significantly simplified in thi= s updated version.=20 Comments welcome.. - Authors -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, July 15, 2013 11:08 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-muthu-behave-consent-freshness-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : STUN Usage for Consent Freshness Author(s) : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Filename : draft-muthu-behave-consent-freshness-04.txt Pages : 7 Date : 2013-07-15 Abstract: Verification of peer consent before sending traffic is necessary in WebRTC deployments to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. A related problem is session liveness. WebRTC application may want to detect connection failure and take appropriate action. This document describes how a WebRTC browser can verify peer consent to continue sending traffic and detect connection failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness There's also a htmlized version available at: http://tools.ietf.org/html/draft-muthu-behave-consent-freshness-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-muthu-behave-consent-freshness-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From adam@nostrum.com Mon Jul 15 12:05:35 2013 Return-Path: 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 EAC6711E823B; Mon, 15 Jul 2013 12:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 SvLWPgGQpNgt; Mon, 15 Jul 2013 12:05:33 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AD0B221E810A; Mon, 15 Jul 2013 12:04:47 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6FJ4k1N035254 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 14:04:46 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E447C8.1000701@nostrum.com> Date: Mon, 15 Jul 2013 14:04:40 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "rtcweb@ietf.org" Subject: [rtcweb] Unified Plan for SDP Handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "mmusic@ietf.org" List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:05:35 -0000 [Cross-posting to RTCWEB; follow-ups to MMUSIC, please] After significant work, Justin, Martin and I have managed to produce a compromise plan that provides a high degree of interoperability with existing devices (and future non-WebRTC devices) while not being excessively onerous for WebRTC implementations or applications that use them. It's been a tricky balancing act, but I think we've found a good mix between the two that can form a solid basis for the working group to move forward. Rather than summarize the key points of the document in this email, I direct interested parties to section 2 of the document, which summarizes the key aspects of the plan in eight relatively concise bullet points. I apologize for the late publication date of this document -- there's actually been a lot more work put into coming up with a unified draft than I originally anticipated, and the production of this document took at least two weeks longer than I expected it to. Note that this document is intended to be a plan for the work to be done in this area, and not a specification in itself. The intention is that its contents are used as the basis for work in several other drafts -- some new, some not -- that form the corpus of work necessary for RTCWEB (and potentially CLUE) to move forward. Except in rare cases, the document does not attempt to explicitly call out venues or documents for such work, as we (or, at the very least, I) anticipate guidance from the various working group chairs to assist in such decisions. Comments prior to Berlin would be very helpful, although this will clearly be a point of significant discussion at the face-to-face meeting. Document link: http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt /a From internet-drafts@ietf.org Mon Jul 15 12:24:03 2013 Return-Path: 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 81B3C11E8230; Mon, 15 Jul 2013 12:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 RCFl4yIOnKJH; Mon, 15 Jul 2013 12:24:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A674D21E8155; Mon, 15 Jul 2013 12:23:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715192354.17142.94001.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 12:23:54 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:24:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : RTCWeb Data Channels Author(s) : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-channel-05.txt Pages : 13 Date : 2013-07-15 Abstract: The Web Real-Time Communication (WebRTC) working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing Web Browser to exchange generic data from peer to peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 15 13:31:30 2013 Return-Path: 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 C236221E816D; Mon, 15 Jul 2013 13:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 YGB5X4iZOlcU; Mon, 15 Jul 2013 13:31:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 698AD21E811A; Mon, 15 Jul 2013 13:31:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715203130.5677.31855.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 13:31:30 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:31:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : WebRTC Data Channel Protocol Author(s) : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-protocol-00.txt Pages : 11 Date : 2013-07-15 Abstract: The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to support for direct interactive rich communication using audio, video, and data between two peers' web- browsers. This document specifies an actual (minor) protocol for how the JS-layer DataChannel objects provide the data channels between the peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From suhasietf@gmail.com Mon Jul 15 13:46:24 2013 Return-Path: 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 02D3921E8184 for ; Mon, 15 Jul 2013 13:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 oRqf0HUaqPcJ for ; Mon, 15 Jul 2013 13:46:23 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C39EC21E8098 for ; Mon, 15 Jul 2013 13:46:22 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so3396660wid.3 for ; Mon, 15 Jul 2013 13:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WifWiOIKHZwUHt/i7E/HDB+2FUOIesB2WqrAUbv44TU=; b=ptN2Bs3HSzuC68SGl7P57od9N96Okb6AR9KJn13VpQpuQbYhVJc9YSxJCHPibaEUsa Sd5pVN/TU3uIRqoqdetJ8wX3oLgq/sN9v7AWdRC/EHZXbt+dYTDSoFHc22OJcmGm16ak grt0yzX0EpJKbSDmSljnSB9u/sqCq+ZuMT237kL7l8c/3FkynBepKuO+h9Svob/uZLPL 0q13NUIdtM+lTJ2vRbF/LbjKZwq75K384JVdReiIQM9/t64jZuWpGiTn0a06n+MzjlTY YoCWXV5xCP0grFbtBJ43FgS+TUUBTGYXSrQdQAOaVGfZNCw6Si51LM00S0sI/9ujE9fZ ZZiw== MIME-Version: 1.0 X-Received: by 10.180.212.70 with SMTP id ni6mr6568522wic.11.1373921181817; Mon, 15 Jul 2013 13:46:21 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Mon, 15 Jul 2013 13:46:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 13:46:21 -0700 Message-ID: From: Suhas Nandakumar To: Ted Hardie Content-Type: multipart/alternative; boundary=001a11c3505efde2a204e192f327 Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Draft agenda for IETF 87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:46:24 -0000 --001a11c3505efde2a204e192f327 Content-Type: text/plain; charset=ISO-8859-1 Hello Chairs I was wondering if we could add "RTCWeb SDP Examples" draft to the Agenda that shows several SDP examples for the most common WebRTC Use-cases. The draft location is : http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-02 Thanks Suhas On Thu, Jul 11, 2013 at 9:51 AM, Ted Hardie wrote: > Greetings, > > Below is an initial draft agenda for the upcoming meeting. Since we have > not yet reached the draft deadline (which is the 15th), there may be new > drafts or updates that result in changes. We did already receive requests > for NAT/Firewall traversal discussion, and the chairs will be working with > the document authors to get them considered in the appropriate groups. > > As folks have probably noticed, we are meeting Thursday and Friday, after > the MMUSIC sessions are complete (they are Tuesday and Wednesday). This > should allow us to discuss the results on our first day. > > Please send feedback or change proposals to the list. > > thanks, > > Ted and Cullen > > Day 1: > > Should SDES be part of WebRTC security practice and, if so, how? > Presentations: 30 minutes > Discussion: 40 minutes > > Post-Plan A/Plan B MMUSIC discussion of impact to RTCWEB documents > Presentation: 30 minutes > Discussion: 30 minutes > > Security document updates > Presentation: 10 minutes > Discussion: 10 minutes > > Day 2: > > Chair Discussion: 10 minutes > > Use Case Requirements updates: > Issues list presentation: 20 minutes > Discussion: 20 minutes > > Data channel: > Issues list presentation: 45 minutes > Discussion: 45 minutes > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c3505efde2a204e192f327 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Chairs

=A0 I was wondering if we could add "R= TCWeb SDP Examples" draft to the Agenda that shows several SDP example= s for the most common WebRTC Use-cases.

The draft = location is :

Thanks
Suhas

On Thu, Jul 11, 2013 at 9:51 AM, Ted Hardie <ted.ietf@gmail.com>= wrote:
Greetings,

Below is an initial draft agenda for the upcoming meeting= .=A0=A0 Since we have not yet reached the draft deadline (which is the 15th= ), there may be new drafts or updates that result in changes.=A0 We did alr= eady receive requests for NAT/Firewall traversal discussion, and the chairs= will be working with the document authors to get them considered in the ap= propriate groups.

As folks have probably noticed, we are meeting Thursday and Friday,=20 after the MMUSIC sessions are complete (they are Tuesday and Wednesday). Th= is should allow us to discuss the results on our first day.

Please = send feedback or change proposals to the list.

thanks,

Ted an= d Cullen

Day 1:

Should SDES be part of=A0 WebRTC security practice and, if so, how?
Pres= entations: 30 minutes
Discussion:=A0 40 minutes

Post-Plan A/Plan = B MMUSIC discussion of impact to RTCWEB documents
Presentation: 30 minut= es
Discussion: 30 minutes

Security document updates
Presentation: 10= minutes
Discussion: 10 minutes

Day 2:

Chair Discussion:= =A0 10 minutes

Use Case Requirements updates:
Issues list present= ation: 20 minutes
Discussion: 20 minutes

Data channel:
Issues list presentation:=A0 45 minutes
Discussion:= 45 minutes



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


--001a11c3505efde2a204e192f327-- From suhasietf@gmail.com Mon Jul 15 13:50:19 2013 Return-Path: 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 98FA511E824F; Mon, 15 Jul 2013 13:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, 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 Fjvf25hrbgol; Mon, 15 Jul 2013 13:50:19 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 720DA11E824E; Mon, 15 Jul 2013 13:50:18 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so2993099wgg.0 for ; Mon, 15 Jul 2013 13:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pSNS3tVJiCGcTfDq8cL1T9sumNGOrMIEEpFe+Sl/Ohs=; b=lp64MAERCYoj/rcscTAXWwYOeGCGIjnrAFobrWkw5vXvtX6sTNbO4Mi2zkO0SHM4Dd ykfWdNx52+jXcRZCLRUGrLwm/M3cnyHz5Kg+vaHoj1O38WHJvf8QAkyFUOydEttu5QwM +w58lOIvzwZEpBzETKBdBHZ+wRwlSLlKz1QSaBqVvaU/b6JVKLM3V1l1vDfV0xF+KsDY J4VidebOkhLglGseCpEdrYHqS8qqoDqhydLCDttfGV16H5jIAfioG3jalN0RAxPAmBQa ttsXXnUMIUUJ4RS+mV/ynX6a9vyjwcwujrUPagT7yBq1dNapYPNdD2SrKUnEiYFSRch6 lTcQ== MIME-Version: 1.0 X-Received: by 10.194.179.33 with SMTP id dd1mr32674769wjc.51.1373921417583; Mon, 15 Jul 2013 13:50:17 -0700 (PDT) Received: by 10.194.243.34 with HTTP; Mon, 15 Jul 2013 13:50:17 -0700 (PDT) In-Reply-To: <37D91FC30D69DE43B61E5EEADD959F1807D30FC1@xmb-aln-x12.cisco.com> References: <20130713232132.21090.66576.idtracker@ietfa.amsl.com> <37D91FC30D69DE43B61E5EEADD959F1807D30FC1@xmb-aln-x12.cisco.com> Date: Mon, 15 Jul 2013 13:50:17 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=089e013d0f800b62fb04e19302da Subject: [rtcweb] New Version Notification for draft-nandakumar-rtcweb-sdp-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:50:19 -0000 --089e013d0f800b62fb04e19302da Content-Type: text/plain; charset=ISO-8859-1 Hello All An updated version of the draft showcasing SDP examples for the most common WebRTC use-cases has be submitted. I would recommend PDF version since that shows embedded images. Please let us know your thoughts. Cheers Suhas Filename: draft-nandakumar-rtcweb-sdp Revision: 02 Title: SDP for the WebRTC Creation date: 2013-07-12 Group: Individual Submission Number of pages: 64 URL: http://www.ietf.org/internet-drafts/draft-nandakumar-rtcweb-sdp-02.txt Status: http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-sdp Htmlized: http://tools.ietf.org/html/draft-nandakumar-rtcweb-sdp-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-nandakumar-rtcweb-sdp-02 Abstract: The Web Real-Time Communication (WebRTC) [WEBRTC] working group is charged to provide protocol support for direct interactive rich communication using audio,video and data between two peers' web browsers. With in the WebRTC framework, Session Description protocol (SDP) [RFC4566] is used for negotiating session capabilities between the peers. Such a negotiataion happens based on the SDP Offer/Answer exchange mechanism described in the RFC 3264 [RFC3264]. This document serves a introductory purpose in describing the role of SDP for the most common WebRTC use-cases. This SDP examples provided in this document is still a work in progress, but aims to align closest to the evolving standards. The IETF Secretariat --089e013d0f800b62fb04e19302da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All

=A0 An updated version of the draft showcasing= SDP examples for the most common WebRTC use-cases has be submitted.
<= div>
I would recommend PDF version since that shows embedded = images.

Please let us know your thoughts.

<= div>Cheers
Suhas

Filename: =A0 = =A0 =A0 =A0draft-nandakumar-rtcweb-sdp
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 SDP for the WebRTC
Creation date: =A0 2013-07-12
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 64
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/= internet-drafts/draft-nandakumar-rtcweb-sdp-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/d= raft-nandakumar-rtcweb-sdp
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-nand= akumar-rtcweb-sdp-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdi= ff?url2=3Ddraft-nandakumar-rtcweb-sdp-02

Abstract:
=A0 =A0The Web Real-Time Communication (WebRTC) [WEBRTC] working group is =A0 =A0charged to provide protocol support for direct interactive rich
=A0 =A0communication using audio,video and data between two peers' web<= br> =A0 =A0browsers. =A0With in the WebRTC framework, Session Description proto= col
=A0 =A0(SDP) [RFC4566] is used for negotiating session capabilities between=
=A0 =A0the peers. =A0Such a negotiataion happens based on the SDP Offer/Ans= wer
=A0 =A0exchange mechanism described in the RFC 3264 [RFC3264].

=A0 =A0This document serves a introductory purpose in describing the role o= f
=A0 =A0SDP for the most common WebRTC use-cases.

=A0 =A0This SDP examples provided in this document is still a work in
=A0 =A0progress, but aims to align closest to the evolving standards.




The IETF Secretariat


--089e013d0f800b62fb04e19302da-- From juberti@google.com Mon Jul 15 14:53:22 2013 Return-Path: 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 1CE8411E8219 for ; Mon, 15 Jul 2013 14:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=0.266, 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 M5LhbUI0AST8 for ; Mon, 15 Jul 2013 14:53:21 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id C20CF21E80DF for ; Mon, 15 Jul 2013 14:53:11 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so3409746wiw.7 for ; Mon, 15 Jul 2013 14:53:10 -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 :content-type; bh=kZJQsxBiAw05nki2tgUF/S1Y5FUUOXBcb0ILt4zUXVs=; b=hG+kkEwuZhGvEMh9XzDy3mRuiLqPZfQsQiFwZ5tS6yfQPMoMb5cv2o61Qj/f71blaV Pfvgj+RX+AL8g5EFsm4PBj1nJeAoaoyJfpu4u9QjJf4gPTcIYLM1BNRaCqc/KkJKoRsH AliE5yT8P1pfrSU6yBhpkHAhsrDnoQHgB9a3pS61WTGjymx+CVZRi89pCGHse/C/KoyX rsgA3my6naU8uhFRRBr0Uhta8G5fF6BdSfekyGaRnqxjDUZg6QPKPaPm0lrALywrZOzG +vt5swu0fJFd++K6Pw4Mj5vqcUwCHrXFhh9E+t9BHvbj0uHIXrGdw6XrLVvz5iKV5109 oXpg== 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 :content-type:x-gm-message-state; bh=kZJQsxBiAw05nki2tgUF/S1Y5FUUOXBcb0ILt4zUXVs=; b=agtdHU7lbj7Ut495nzVm6SousyAikkD99Thh32JPuazoWgKK/chWHVwpblsrdr/7/I 73RJdo0yH9oMlGAmS720H5ZCviaX1mTFrUpqiC6yYzpoCNqoqW3rNSjhGf2TF1mPTpRJ zELsn9b+ticQcRkqjw3EBxrib/xzDATrb+ypNvVmMbKkJxq/BcDUJg3O2jEx9qUJoHlA /YGRl5tm3ahZPdB+fpeT06htMMIOaq1bELCiIYA5HPBejnF0Iwq7Tt9rZtpic9f54Yjp vALJgZD+5DA+T9imLIwmn7rbgZ+24fO1aSIr+AG5qHQMe4BikR+4fupFEdLWmK4qjRlJ rB2g== X-Received: by 10.194.58.239 with SMTP id u15mr33051859wjq.87.1373925190894; Mon, 15 Jul 2013 14:53:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Mon, 15 Jul 2013 14:52:50 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Mon, 15 Jul 2013 17:52:50 -0400 Message-ID: To: "rtcweb@ietf.org" , behave@ietf.org Content-Type: multipart/alternative; boundary=047d7ba97b94f39ea604e193e2dd X-Gm-Message-State: ALoCoQlmRmyndm7xcRjCtCR6xvLDt8VtVJN3yoU/MH2GI7hZllPj8lV0RzOg1tueyvhhIMZUMQs/+cg4dD3SJf0jJlSYxUwFB5ZlX9pGjBa0+HDBH9jI1l8xZfEtMdUsEEQDzTLuHp8Vp5CNIB9BGV672Ok4cI/8CXbGhk4jgh/KlnYXIYlsC9CuT/lcfHucgWjovWWe8S91 Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:53:22 -0000 --047d7ba97b94f39ea604e193e2dd Content-Type: text/plain; charset=UTF-8 I have changed the WG for this draft from RTCWEB to BEHAVE. Many, but not all of the comments I received on the RTCWEB mailing list have been addressed. BEHAVE chairs, I would like 10 minutes of agenda time to discuss this draft. ---------- Forwarded message ---------- From: Date: Mon, Jul 15, 2013 at 5:49 PM Subject: New Version Notification for draft-uberti-behave-turn-rest-00.txt To: Justin Uberti A new version of I-D, draft-uberti-behave-turn-rest-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: draft-uberti-behave-turn-rest Revision: 00 Title: A REST API For Access To TURN Services Creation date: 2013-07-15 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt Status: http://datatracker.ietf.org/doc/draft-uberti-behave-turn-rest Htmlized: http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 Abstract: This document describes a proposed standard REST API for obtaining access to TURN services via ephemeral (i.e. time-limited) credentials. These credentials are vended by a web service over HTTP, and then supplied to and checked by a TURN server using the standard TURN protocol. The usage of ephemeral credentials ensures that access to the TURN server can be controlled even if the credentials can be discovered by the user, as is the case in WebRTC where TURN credentials must be specified in Javascript. The IETF Secretariat --047d7ba97b94f39ea604e193e2dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have changed the WG for this draft from RTCWEB to BEHAVE= . Many, but not all of the comments I received on the RTCWEB mailing list h= ave been addressed.

BEHA= VE chairs, I would like 10 minutes of agenda time to discuss this draft.
---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
Date: Mon, Jul 15, 2013 at 5:49 PM
Subject: New Version Notification for= draft-uberti-behave-turn-rest-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-behave-turn-rest-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-uberti-behave-turn-rest
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A REST API For Access To TURN Ser= vices
Creation date: =C2=A0 2013-07-15
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 8
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatrack= er.ietf.org/doc/draft-uberti-behave-turn-rest
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h= tml/draft-uberti-behave-turn-rest-00


Abstract:
=C2=A0 =C2=A0This document describes a proposed standard REST API for obtai= ning
=C2=A0 =C2=A0access to TURN services via ephemeral (i.e. time-limited)
=C2=A0 =C2=A0credentials. =C2=A0These credentials are vended by a web servi= ce over
=C2=A0 =C2=A0HTTP, and then supplied to and checked by a TURN server using = the
=C2=A0 =C2=A0standard TURN protocol. =C2=A0The usage of ephemeral credentia= ls ensures
=C2=A0 =C2=A0that access to the TURN server can be controlled even if the =C2=A0 =C2=A0credentials can be discovered by the user, as is the case in W= ebRTC
=C2=A0 =C2=A0where TURN credentials must be specified in Javascript.




The IETF Secretariat



--047d7ba97b94f39ea604e193e2dd-- From internet-drafts@ietf.org Mon Jul 15 14:57:40 2013 Return-Path: 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 45BA321F9FC8; Mon, 15 Jul 2013 14:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 u0ZTA8U7XyZl; Mon, 15 Jul 2013 14:57:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7F221F9FFC; Mon, 15 Jul 2013 14:57:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715215726.14640.21291.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:57:26 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:57:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport an= d Use of RTP Author(s) : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-07.txt Pages : 61 Date : 2013-07-15 Abstract: The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pthatcher@google.com Mon Jul 15 17:44:25 2013 Return-Path: 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 7ECB221E8084 for ; Mon, 15 Jul 2013 17:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.046, 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 iKn-9bngAY6C for ; Mon, 15 Jul 2013 17:44:25 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9A521E811C for ; Mon, 15 Jul 2013 17:44:20 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id q10so78860pdj.10 for ; Mon, 15 Jul 2013 17:44:19 -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=MTTGAt6BjaCfAWf+RZn6rfKR3BWPEAwz+HLEdZE5K2o=; b=FCcOVKkZAEkhvjjVVtwCalzknCMzTxNqYwF+CTOF2hwUizwom+3f03OQtq+59tne+O KxGprT3K/zMgLsyjDFre5Iqm8vu5HbCvZwUdiECMpYpeBA+5ZhSlRZrWwaH1DU+DIraa 8jBtQ/OhjcCfBY8K9kFq5n6FlJOmjSTrF7821UraJLRBMzgieyVdFyM4LwXGEXQiAHYc 8xF0tDMAWQCozkfSk/30oiHHZPERBv515GLM1mnefnwXzc9R/rC3UTOU8Gxu62k4lP1A gQzvNyRUc+3NfYEeGLtP5WnvrVHt7fp+jn2LS0/jvZmOONMmfryrdDsJHhihgJPRgfHv /cwQ== 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=MTTGAt6BjaCfAWf+RZn6rfKR3BWPEAwz+HLEdZE5K2o=; b=R4IeEraC1fWb7e9E1z9SkcILVtOxaDUvvgxdkb6JdZxwXzK9gK9Dx5iw/LqaIt5Los 1tKa7RwUXx6iiPnHg2+SpCpQ4Pk1V105vozhaGm1V8Xkcaw5d+n/vZJ4/b/Ljz3Flwkx vE92twYZ6hWbeMMcwckuQaeK7hGc/0cZc0XGwh4GpH39KXaN4OLs04H/dWh/ODHg5EGl 49sX3ly25GDDnIHNdI+t0qWWssii/XjX8X9e/lKpivdu0fA/O0Hh7ramDyLIFdtxDwSk 6bNC5WyOLY25obh7bPmTB/rBJVTHdJ0EFkmHZJy4gVYAa3ck3xIGuUToA/aT5y+KEVed NCDw== X-Received: by 10.68.219.130 with SMTP id po2mr55797330pbc.54.1373935459679; Mon, 15 Jul 2013 17:44:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 15 Jul 2013 17:43:38 -0700 (PDT) In-Reply-To: <20130715203130.5677.31855.idtracker@ietfa.amsl.com> References: <20130715203130.5677.31855.idtracker@ietfa.amsl.com> From: Peter Thatcher Date: Mon, 15 Jul 2013 17:43:38 -0700 Message-ID: To: internet-drafts@ietf.org, Randell Jesup Content-Type: multipart/alternative; boundary=e89a8ff2488104dbb904e196472b X-Gm-Message-State: ALoCoQli9ixo6uvtyKShBO8K1tfVMgDtXPID25OpgnHdeb169Zge7YauAQHT5LBcxIxEyeI7LraXLMIhXZxL24cky1fjrMQxgrGbywZgqHnLgxIEScknWvSteo60lCOdzcqzT1DCOvXSXuNWLtn5pdTE2rPXHqqNc5Rrux/n+uBtmIEBSOhT4gIAsRLSbNYt0x9wR2Nqx9s3 Cc: "" , i-d-announce@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 00:44:25 -0000 --e89a8ff2488104dbb904e196472b Content-Type: text/plain; charset=UTF-8 Hey Randell, can you give a short summary of the changes, if any, that I would or other implementors would need to know about? On Mon, Jul 15, 2013 at 1:31 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. > > Title : WebRTC Data Channel Protocol > Author(s) : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-protocol-00.txt > Pages : 11 > Date : 2013-07-15 > > Abstract: > The Web Real-Time Communication (WebRTC) working group is charged to > provide protocols to support for direct interactive rich > communication using audio, video, and data between two peers' web- > browsers. This document specifies an actual (minor) protocol for how > the JS-layer DataChannel objects provide the data channels between > the peers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --e89a8ff2488104dbb904e196472b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Randell, can you give a short summary of the changes, = if any, that I would or other implementors would need to know about?
<= div class=3D"gmail_extra">

On Mon, Jul 15= , 2013 at 1:31 PM, <internet-drafts@ietf.org> wrote:=

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : WebR= TC Data Channel Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Randell Jesup<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Salvatore Loreto
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael Tuexen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-rtcweb-data-protocol-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 11 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2013-07-15

Abstract:
=C2=A0 =C2=A0The Web Real-Time Communication (WebRTC) working group is char= ged to
=C2=A0 =C2=A0provide protocols to support for direct interactive rich
=C2=A0 =C2=A0communication using audio, video, and data between two peers&#= 39; web-
=C2=A0 =C2=A0browsers. =C2=A0This document specifies an actual (minor) prot= ocol for how
=C2=A0 =C2=A0the JS-layer DataChannel objects provide the data channels bet= ween
=C2=A0 =C2=A0the peers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data= -protocol

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol= -00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--e89a8ff2488104dbb904e196472b-- From pthatcher@google.com Mon Jul 15 17:44:26 2013 Return-Path: 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 DCE1021E8105 for ; Mon, 15 Jul 2013 17:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.044, 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 y5AcpzMAKQ+T for ; Mon, 15 Jul 2013 17:44:26 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C2BCE21E811C for ; Mon, 15 Jul 2013 17:44:25 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so75365pdi.30 for ; Mon, 15 Jul 2013 17:44: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=tsVM0TTVTRXBbdcYyQbjRCCLSfbpr4/Ejt2d0Dz/k/4=; b=LWxXy0WmSq61Bk7BG5KOf6woFd5o9kABEoc6Dkwwh6Ts9eG9vCsirvmsAJ/IoqVfvh ++xUAJvJhtfEuzbnx2buPhRDdMAEp8RBQKF6sETysMF8TkV/9HU0fqZ6Car+W8rsuSIw Kka82aBJQvBYUBnEpdTyOPbdjKlsBLT1nZYP5FVHbFMoH+2ZPa9ruq57tMF1ZI5SOcOG TjnjMz1z6rvileQXnmbUYQqaP5vMmDiUpBElO9ScnOs/XX59uP6Wxc6BPsZIJeg2pOBM mxWE56a5ItSrOQM8Uae9HIXLOfClxOtbUEBubjrFFt8/P+qhnLwnv1Lkir6/OBCLowOm K3ZA== 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=tsVM0TTVTRXBbdcYyQbjRCCLSfbpr4/Ejt2d0Dz/k/4=; b=VvOjyeEKiNCUO7MV4Ezq0hslLFfESPkQbfQjpd3JJHNjSOoeZNAiXhtWTmOsazprwU ub9BY1lDxgHNLmag2qYqPRHv/SixvIMrBnD8dFP4ys/IMvliuqjBOUfgi1vGODFg+seC z0nr1jWSaFNph87vZ9uDiF0ol/djUihY1WMoBXl/NLpgpiMpSAtwQAzAhy6Pm91LE60W oPVI5YJq9DRsILSdi01mg/h4RdkXcEGgA7ZBPsYjA8h8iKLXmPgm7vT+3vAjTUeaVqRq wRCtXoJcUq1vntxzqMJm41l5QeCBMe2/XYx7e+s7Wet2ESI0WVNpfQfNXcmE3xnwd1HU 7OGQ== X-Received: by 10.66.141.4 with SMTP id rk4mr57047030pab.127.1373935465433; Mon, 15 Jul 2013 17:44:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.169 with HTTP; Mon, 15 Jul 2013 17:43:45 -0700 (PDT) In-Reply-To: <20130715192354.17142.94001.idtracker@ietfa.amsl.com> References: <20130715192354.17142.94001.idtracker@ietfa.amsl.com> From: Peter Thatcher Date: Mon, 15 Jul 2013 17:43:45 -0700 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=001a11c39d185caa7004e19647c7 X-Gm-Message-State: ALoCoQkASKncG7R3L25G3qpI/p3VDhXdjI9Fy5pxuMpVlqyNd0BXL25j/WcV2OoqYTE0gLEGFxgrRVcy5fbve2/DnMv0ZaepwBSaEsMTqt9muSph8nCOKpsencbICsIAO9QgFDWp943bla3/IZd5m63TMgeQ9h0CeVF8IyVRBPlGRgGt+vGh1bqyxoPbiemoCeZyJCkeZbY2 Cc: "" , i-d-announce@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 00:44:27 -0000 --001a11c39d185caa7004e19647c7 Content-Type: text/plain; charset=UTF-8 Hey Randell, can you give a short summary of the changes, if any, that I would or other implementors would need to know about? On Mon, Jul 15, 2013 at 12:23 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > Working Group of the IETF. > > Title : RTCWeb Data Channels > Author(s) : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-channel-05.txt > Pages : 13 > Date : 2013-07-15 > > Abstract: > The Web Real-Time Communication (WebRTC) working group is charged to > provide protocol support for direct interactive rich communication > using audio, video, and data between two peers' web-browsers. This > document specifies the non-media data transport aspects of the WebRTC > framework. It provides an architectural overview of how the Stream > Control Transmission Protocol (SCTP) is used in the WebRTC context as > a generic transport service allowing Web Browser to exchange generic > data from peer to peer. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-channel-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c39d185caa7004e19647c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Randell, can you give a short summary of the changes, = if any, that I would or other implementors would need to know about?


On Mon, Ju= l 15, 2013 at 12:23 PM, <internet-drafts@ietf.org> w= rote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Real-Time Communication in WEB-brows= ers Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : RTCW= eb Data Channels
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Randell Jesup<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Salvatore Loreto
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael Tuexen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-rtcweb-data-channel-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 13 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2013-07-15

Abstract:
=C2=A0 =C2=A0The Web Real-Time Communication (WebRTC) working group is char= ged to
=C2=A0 =C2=A0provide protocol support for direct interactive rich communica= tion
=C2=A0 =C2=A0using audio, video, and data between two peers' web-browse= rs. =C2=A0This
=C2=A0 =C2=A0document specifies the non-media data transport aspects of the= WebRTC
=C2=A0 =C2=A0framework. =C2=A0It provides an architectural overview of how = the Stream
=C2=A0 =C2=A0Control Transmission Protocol (SCTP) is used in the WebRTC con= text as
=C2=A0 =C2=A0a generic transport service allowing Web Browser to exchange g= eneric
=C2=A0 =C2=A0data from peer to peer.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-= channel

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-0= 5

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcwe= b-data-channel-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--001a11c39d185caa7004e19647c7-- From mperumal@cisco.com Tue Jul 16 03:49:15 2013 Return-Path: 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 C076E11E80AE; Tue, 16 Jul 2013 03:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Qfj1aG5b7bxd; Tue, 16 Jul 2013 03:49:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3E63321E8091; Tue, 16 Jul 2013 03:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6594; q=dns/txt; s=iport; t=1373971750; x=1375181350; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Po4m7Ra9CAvA43jLU366UxgT7gkxW2+ystwk/lVI/Pw=; b=b6mw8HJ6RG/DecOFPmBRKVNGzhf5V7loTsQTSXnRU694P1sdWJAgqlm7 pzEPSPpwSVySXNvGshmZlJ1I+qQLXrDIDgrKNq7xo8F2xIAgwfuysxoTe kpbXplFshrSM2QItDCCaSdNDavsV/ohtp8neskPeFsXwfu4RJl/3BIo7Y M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFADck5VGtJXG//2dsb2JhbABagwY0T8FegREWdIIjAQEBBAEBAWsXBAIBCBEEAQELDg8HJwsUCAEIAgQBEggTh3UMthoEjzM4BhKCc20DiG+UYYtZgxKBaiQa X-IronPort-AV: E=Sophos;i="4.89,676,1367971200"; d="scan'208";a="235447897" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2013 10:49:08 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GAn8nW007407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 10:49:08 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 05:49:07 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Simon Perreault , "behave@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOggfD5W/HlPrVS02D/hotnG5s6plnD7Qg Date: Tue, 16 Jul 2013 10:49:07 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> In-Reply-To: <51E513BF.2040405@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.173] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 10:49:15 -0000 [Added rtcweb since I am not sure if everyone involved there are following = this discussion in behave] Thanks for the review. See inline..=20 |-----Original Message----- |From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf O= f Simon Perreault |Sent: Tuesday, July 16, 2013 3:05 PM |To: behave@ietf.org |Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt | |Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |> The text and the algorithm in the draft are significantly simplified in = this updated version. |> |> Comments welcome.. | |MUCH better introduction. Now I feel like I understand the need exactly. | |The "Design Considerations" section is still very confusing to me. | |> Though ICE specifies STUN Binding indications to be used for |> keepalives, it requires that an agent be prepared to receive |> connectivity check as well. If a connectivity check is received, a |> response is generated, but there is no impact on ICE processing, as |> described in section 10 of [RFC5245]. | |...so? Why is "an impact on ICE processing" necessary? Meant to stress these Binding request/response doesn't trigger an ICE resta= rt.. | |> While a WebRTC browser could verify whether the peer continues to |> send SRTCP reports before sending traffic to the peer, the usage of |> SRTCP together with Security Descriptions [RFC4568] requires exposing |> the media keys to the JavaScript and renders SRTCP unsuitable for |> consent freshness. | |Why does it "require exposing the media keys to the JavaScript"? Is this |because of a law of nature, or is it because of the way the JavaScript |API is being designed? Could the JS API be changed to accommodate |SRTCP+SDES? That's how the API construct looks like today -- the JavaScript would get a= n SDP blob from the browser containing the crypto keys used for SDES-SRTP. = Of course, the browser could hide those keys by putting a "****" in SDP -:)= . SRTP itself is still being debated in RTCWEB, so nothing is final, yet. | |> For consent, calculating the SHA1 HMAC is necessary for MESSAGE- |> INTEGRITY which is computationally expensive. | |You need to qualify "expensive". It's certainly not expensive in all cases= . | |> Security analysis |> concluded that the STUN 96 bits transaction ID is sufficient for |> consent, without needing MESSAGE-INTEGRITY. | |What analysis? You would need to explain it in detail. But if that's not |part of your suggested solution, just remove the sentence. Agree it could be elaborated. The intention was to say the foll: STUN requires the 96 bits transaction ID to be uniformly and randomly chosen from the interval 0 .. 2**96-1, and be cryptographically random. This should suffice to prevent off path attacks on consent=20 freshness, so MESSAGE-INTEGRITY is not necessary from a security perspective. However, MESSAGE-INTEGRITY is still used to maintain backward compatibility= =20 with legacy ICE/ICE-lite implementations. | |Now on to section "4. Solution Overview"... | |> Every Tc seconds, the WebRTC browser sends a STUN Binding Request to |> the peer. This request MUST use a new, cryptographically random |> Transaction ID [RFC4086], and is formatted as for an ICE connectivity |> check [RFC5245]. A valid STUN Binding Response is also formatted as |> for an ICE connectivity check [RFC5245]. The STUN Binding Request |> and STUN Binding Response are validated as for an ICE connectivity |> check [RFC5245]. | |Couldn't this whole paragraph be simplified to "Every Tc seconds, the |WebRTC browser sends an ICE connectivity check."? Is there anything new |here besides the "every Tc" thing? The difference from the ICE connectivity check is that there is no exponent= ial back off for retransmissions. =20 | |> Liveness timer: If no packets have been received on the local port in |> Tr seconds, the WebRTC browser MUST inform the JavaScript that |> connectivity has been lost. The JavaScript application will use this |> notification however it desires (e.g., cease transmitting to the |> remote peer, provide a notification to the user, etc.). | |This seems to me like it will not fulfill the goal set in the abstract: |"to ensure that a malicious JavaScript cannot use the browser as a |platform for launching attacks". If the JavaScript is free to ignore the |notification from the browser, then it has no security benefits. If you |want to reach that goal, the browser needs to forcefully stop transmitting= . That goal is fulfilled by the consent checks -- the browser would stop tran= smitting everything on that candidate pair, including liveness checks, if t= here is a consent failure. | |> When not actively sending traffic on a nominated candidate pair, |> performing consent freshness does not serve any purpose from a |> security perspective. | |I don't understand what this means. Why is the "security perspective" |important here? Aren't we concerned about keepalives? You mean one could use keepalives (Binding indications) for launching attac= ks, so consent freshness would be required for sending them as well? | |> In ICE [RFC5245] the STUN request/response are protected with |> MESSAGE-INTEGRITY, using an ephemeral username and password exchanged |> in the SDP ice-ufrag and ice-pwd attributes. This prevents ICE from |> accidentally connecting to an in-intended peer, in that ICE will only |> connect to a peer that also knows the same username and password |> (exchanged in call signaling). Once that connection to the remote |> peer has been established with ICE, the consent to continue sending |> traffic does not benefit from re-asserting that same username and |> password, so long as the senders and receiver's IP addresses remain |> the same (as they usually do). | |I had not understood from the text that there was no auth stuff in the |request. The text said "This request [...] is formatted as for an ICE |connectivity check [RFC5245]." I thought that included auth stuff. | |The explanation why no auth stuff in the request is acceptable should be |moved to section 3. Agree, it could be moved under design considerations. Muthu=20 | |Simon |_______________________________________________ |Behave mailing list |Behave@ietf.org |https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Tue Jul 16 05:04:21 2013 Return-Path: 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 6794821E805F; Tue, 16 Jul 2013 05:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 kr0OM1chKled; Tue, 16 Jul 2013 05:04:20 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 06B3711E80D7; Tue, 16 Jul 2013 05:04:17 -0700 (PDT) Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A197B470FB; Tue, 16 Jul 2013 08:04:15 -0400 (EDT) Message-ID: <51E536C1.1080507@viagenie.ca> Date: Tue, 16 Jul 2013 14:04:17 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 12:04:21 -0000 Le 2013-07-16 12:49, Muthu Arul Mozhi Perumal (mperumal) a écrit : > |> Though ICE specifies STUN Binding indications to be used for > |> keepalives, it requires that an agent be prepared to receive > |> connectivity check as well. If a connectivity check is received, a > |> response is generated, but there is no impact on ICE processing, as > |> described in section 10 of [RFC5245]. > | > |...so? Why is "an impact on ICE processing" necessary? > > Meant to stress these Binding request/response doesn't trigger an ICE restart.. Ok, then s/but/and/. > |> While a WebRTC browser could verify whether the peer continues to > |> send SRTCP reports before sending traffic to the peer, the usage of > |> SRTCP together with Security Descriptions [RFC4568] requires exposing > |> the media keys to the JavaScript and renders SRTCP unsuitable for > |> consent freshness. > | > |Why does it "require exposing the media keys to the JavaScript"? Is this > |because of a law of nature, or is it because of the way the JavaScript > |API is being designed? Could the JS API be changed to accommodate > |SRTCP+SDES? > > That's how the API construct looks like today -- the JavaScript would get an SDP blob from the browser containing the crypto keys used for SDES-SRTP. Of course, the browser could hide those keys by putting a "****" in SDP -:). SRTP itself is still being debated in RTCWEB, so nothing is final, yet. Ok, then say so in the draft. > |> Security analysis > |> concluded that the STUN 96 bits transaction ID is sufficient for > |> consent, without needing MESSAGE-INTEGRITY. > | > |What analysis? You would need to explain it in detail. But if that's not > |part of your suggested solution, just remove the sentence. > > Agree it could be elaborated. The intention was to say the foll: > > STUN requires the 96 bits transaction ID to be uniformly and randomly > chosen from the interval 0 .. 2**96-1, and be cryptographically > random. This should suffice to prevent off path attacks on consent > freshness, so MESSAGE-INTEGRITY is not necessary from a security > perspective. > > However, MESSAGE-INTEGRITY is still used to maintain backward compatibility > with legacy ICE/ICE-lite implementations. Ok, then say so in the draft. > |Now on to section "4. Solution Overview"... > | > |> Every Tc seconds, the WebRTC browser sends a STUN Binding Request to > |> the peer. This request MUST use a new, cryptographically random > |> Transaction ID [RFC4086], and is formatted as for an ICE connectivity > |> check [RFC5245]. A valid STUN Binding Response is also formatted as > |> for an ICE connectivity check [RFC5245]. The STUN Binding Request > |> and STUN Binding Response are validated as for an ICE connectivity > |> check [RFC5245]. > | > |Couldn't this whole paragraph be simplified to "Every Tc seconds, the > |WebRTC browser sends an ICE connectivity check."? Is there anything new > |here besides the "every Tc" thing? > > The difference from the ICE connectivity check is that there is no exponential back off for retransmissions. Ok, then say so in the draft. > |> Liveness timer: If no packets have been received on the local port in > |> Tr seconds, the WebRTC browser MUST inform the JavaScript that > |> connectivity has been lost. The JavaScript application will use this > |> notification however it desires (e.g., cease transmitting to the > |> remote peer, provide a notification to the user, etc.). > | > |This seems to me like it will not fulfill the goal set in the abstract: > |"to ensure that a malicious JavaScript cannot use the browser as a > |platform for launching attacks". If the JavaScript is free to ignore the > |notification from the browser, then it has no security benefits. If you > |want to reach that goal, the browser needs to forcefully stop transmitting. > > That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on that candidate pair, including liveness checks, if there is a consent failure. That's not what the draft says. It says that the browser "notifies" the JS app. It needs to say that the browser MUST stop sending. > |> When not actively sending traffic on a nominated candidate pair, > |> performing consent freshness does not serve any purpose from a > |> security perspective. > | > |I don't understand what this means. Why is the "security perspective" > |important here? Aren't we concerned about keepalives? > > You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness would be required for sending them as well? No. This is a section about keepalives. I just don't understand this sentence, and I don't understand why it talks about security. Simon From mperumal@cisco.com Tue Jul 16 05:43:32 2013 Return-Path: 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 E032A11E80D7; Tue, 16 Jul 2013 05:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 MNF-AY3tkM+n; Tue, 16 Jul 2013 05:43:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1100021F9C4F; Tue, 16 Jul 2013 05:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6200; q=dns/txt; s=iport; t=1373978607; x=1375188207; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LsbzuIhIyAnXUeD6G6plhhi4nUlH2PrPe91sDRqnMdg=; b=eC+sK2jLvvpVOT7m/1jFIsYs986ugDmhW10SxPPqruvDl9YN5k/7FkHf 5SQ35oRU9ZLBMKEw5kl48x4/KTLy21Sb7y8MNUv+AuWAuwiDAi+iwp7Pz OQLnSzrhACUceKq1XF3EFF84yIVGdDlO16e5qcV5AkZUtpPpZiramPhGZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFADs/5VGtJV2b/2dsb2JhbABagwaBA8FdgQ4WdIIjAQEBBHkMBAIBCBEEAQELHQcyFAgBCAIEDgUIE4d1tiaPLjEHBoMGbQOIb6A6gxKBaiQa X-IronPort-AV: E=Sophos;i="4.89,676,1367971200"; d="scan'208";a="235403631" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 16 Jul 2013 12:43:26 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GChQrI011223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 12:43:26 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 07:43:26 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Simon Perreault Thread-Topic: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiIQwKpPGdZXK0Ooeh9Y1O+0Lw== Date: Tue, 16 Jul 2013 12:43:26 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> In-Reply-To: <51E536C1.1080507@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.66] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 12:43:33 -0000 Inline.. |-----Original Message----- |From: Simon Perreault [mailto:simon.perreault@viagenie.ca] |Sent: Tuesday, July 16, 2013 5:34 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: behave@ietf.org; rtcweb@ietf.org |Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt | |Le 2013-07-16 12:49, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |> |> Though ICE specifies STUN Binding indications to be used for |> |> keepalives, it requires that an agent be prepared to receive |> |> connectivity check as well. If a connectivity check is received, = a |> |> response is generated, but there is no impact on ICE processing, a= s |> |> described in section 10 of [RFC5245]. |> | |> |...so? Why is "an impact on ICE processing" necessary? |> |> Meant to stress these Binding request/response doesn't trigger an ICE re= start.. | |Ok, then s/but/and/. | |> |> While a WebRTC browser could verify whether the peer continues to |> |> send SRTCP reports before sending traffic to the peer, the usage o= f |> |> SRTCP together with Security Descriptions [RFC4568] requires expos= ing |> |> the media keys to the JavaScript and renders SRTCP unsuitable for |> |> consent freshness. |> | |> |Why does it "require exposing the media keys to the JavaScript"? Is thi= s |> |because of a law of nature, or is it because of the way the JavaScript |> |API is being designed? Could the JS API be changed to accommodate |> |SRTCP+SDES? |> |> That's how the API construct looks like today -- the JavaScript would ge= t an SDP blob from the |browser containing the crypto keys used for SDES-SRTP. Of course, the brow= ser could hide those keys by |putting a "****" in SDP -:). SRTP itself is still being debated in RTCWEB,= so nothing is final, yet. | |Ok, then say so in the draft. | |> |> Security analysis |> |> concluded that the STUN 96 bits transaction ID is sufficient for |> |> consent, without needing MESSAGE-INTEGRITY. |> | |> |What analysis? You would need to explain it in detail. But if that's no= t |> |part of your suggested solution, just remove the sentence. |> |> Agree it could be elaborated. The intention was to say the foll: |> |> STUN requires the 96 bits transaction ID to be uniformly and randomly |> chosen from the interval 0 .. 2**96-1, and be cryptographically |> random. This should suffice to prevent off path attacks on consent |> freshness, so MESSAGE-INTEGRITY is not necessary from a security |> perspective. |> |> However, MESSAGE-INTEGRITY is still used to maintain backward compatibil= ity |> with legacy ICE/ICE-lite implementations. | |Ok, then say so in the draft. | |> |Now on to section "4. Solution Overview"... |> | |> |> Every Tc seconds, the WebRTC browser sends a STUN Binding Request = to |> |> the peer. This request MUST use a new, cryptographically random |> |> Transaction ID [RFC4086], and is formatted as for an ICE connectiv= ity |> |> check [RFC5245]. A valid STUN Binding Response is also formatted = as |> |> for an ICE connectivity check [RFC5245]. The STUN Binding Request |> |> and STUN Binding Response are validated as for an ICE connectivity |> |> check [RFC5245]. |> | |> |Couldn't this whole paragraph be simplified to "Every Tc seconds, the |> |WebRTC browser sends an ICE connectivity check."? Is there anything new |> |here besides the "every Tc" thing? |> |> The difference from the ICE connectivity check is that there is no expon= ential back off for |retransmissions. | |Ok, then say so in the draft. | |> |> Liveness timer: If no packets have been received on the local port= in |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that |> |> connectivity has been lost. The JavaScript application will use t= his |> |> notification however it desires (e.g., cease transmitting to the |> |> remote peer, provide a notification to the user, etc.). |> | |> |This seems to me like it will not fulfill the goal set in the abstract: |> |"to ensure that a malicious JavaScript cannot use the browser as a |> |platform for launching attacks". If the JavaScript is free to ignore th= e |> |notification from the browser, then it has no security benefits. If you |> |want to reach that goal, the browser needs to forcefully stop transmitt= ing. |> |> That goal is fulfilled by the consent checks -- the browser would stop t= ransmitting everything on |that candidate pair, including liveness checks, if there is a consent fail= ure. | |That's not what the draft says. It says that the browser "notifies" the |JS app. It needs to say that the browser MUST stop sending. No. That section is about liveness check and its intention is just notify t= he JavaScript of a potential connectivity loss. It is when the consent chec= k fails the browser actually stops sending everything. Does the draft need = more text on the distinction between consent and liveness tests? | |> |> When not actively sending traffic on a nominated candidate pair, |> |> performing consent freshness does not serve any purpose from a |> |> security perspective. |> | |> |I don't understand what this means. Why is the "security perspective" |> |important here? Aren't we concerned about keepalives? |> |> You mean one could use keepalives (Binding indications) for launching at= tacks, so consent freshness |would be required for sending them as well? | |No. | |This is a section about keepalives. I just don't understand this |sentence, and I don't understand why it talks about security. Ok, let me elaborate: - Consent freshness is not necessary when the browser is not sending any=20 traffic on a candidate pair. - If the browser is not performing consent freshness on a candidate pair=20 for the above reason, it performs ICE keepalives (or RTP keepalives) to refresh NAT bindings. Of course, the browser could continue performing consent freshness even whe= n it is not sending any other traffic on that candidate pair and skip ICE k= eepalives. Muthu | |Simon From simon.perreault@viagenie.ca Tue Jul 16 06:04:00 2013 Return-Path: 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 A1F1821F9A1E; Tue, 16 Jul 2013 06:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 y2jWGTIflMph; Tue, 16 Jul 2013 06:04:00 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 60EE211E80F3; Tue, 16 Jul 2013 06:03:59 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:5b8:1f9e:c21b:48d7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 57898470FB; Tue, 16 Jul 2013 09:03:58 -0400 (EDT) Message-ID: <51E544BC.6000608@viagenie.ca> Date: Tue, 16 Jul 2013 15:03:56 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:04:00 -0000 Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a écrit : > |> |> Liveness timer: If no packets have been received on the local port in > |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that > |> |> connectivity has been lost. The JavaScript application will use this > |> |> notification however it desires (e.g., cease transmitting to the > |> |> remote peer, provide a notification to the user, etc.). > |> | > |> |This seems to me like it will not fulfill the goal set in the abstract: > |> |"to ensure that a malicious JavaScript cannot use the browser as a > |> |platform for launching attacks". If the JavaScript is free to ignore the > |> |notification from the browser, then it has no security benefits. If you > |> |want to reach that goal, the browser needs to forcefully stop transmitting. > |> > |> That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on > |that candidate pair, including liveness checks, if there is a consent failure. > | > |That's not what the draft says. It says that the browser "notifies" the > |JS app. It needs to say that the browser MUST stop sending. > > No. That section is about liveness check and its intention is just notify the JavaScript of a potential connectivity loss. It is when the consent check fails the browser actually stops sending everything. Does the draft need more text on the distinction between consent and liveness tests? Ah! No, you're right, and the text is already perfectly clear about this. No need to change. I was just confused. > |> |> When not actively sending traffic on a nominated candidate pair, > |> |> performing consent freshness does not serve any purpose from a > |> |> security perspective. > |> | > |> |I don't understand what this means. Why is the "security perspective" > |> |important here? Aren't we concerned about keepalives? > |> > |> You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness > |would be required for sending them as well? > | > |No. > | > |This is a section about keepalives. I just don't understand this > |sentence, and I don't understand why it talks about security. > > Ok, let me elaborate: > - Consent freshness is not necessary when the browser is not sending any > traffic on a candidate pair. > - If the browser is not performing consent freshness on a candidate pair > for the above reason, it performs ICE keepalives (or RTP keepalives) to > refresh NAT bindings. > > Of course, the browser could continue performing consent freshness even when it is not sending any other traffic on that candidate pair and skip ICE keepalives. Ah, ok I understand with your explanation. It makes sense. There should be a way to reformulate the text to make it clearer. Thanks, Simon From andrew.hutton@siemens-enterprise.com Tue Jul 16 06:22:43 2013 Return-Path: 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 DBAAC21F9E52 for ; Tue, 16 Jul 2013 06:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 MdwYObENSvwy for ; Tue, 16 Jul 2013 06:22:37 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 39EFC21F9D5D for ; Tue, 16 Jul 2013 06:22:35 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 60DC21EB868E; Tue, 16 Jul 2013 15:22:30 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 15:22:30 +0200 From: "Hutton, Andrew" To: Hadriel Kaplan , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A compromise for SDES Thread-Index: AQHOf/PaSlG3FppoJEmuQYWCyF5yOplnS25Q Date: Tue, 16 Jul 2013 13:22:30 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1164963D@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:22:43 -0000 > On: 13 July 2013 19:07 Hadriel Kaplan Wrote: > To: rtcweb@ietf.org > Subject: [rtcweb] A compromise for SDES >=20 > Howdy, > Someone's asked me to explain the compromise I plan on presenting in > Berlin now, so we have more time to argue over it or chew on it. The > reason I was going to wait is because I wanted to explain how I got to > the point of thinking such a compromise would make sense. So I'll try > to do that in this email, which will make this email long. Nothin' > much I can do about that. >=20 > Obviously this is all my personal opinion, not that of my employer, and > not a statement claiming to be objective fact, etc. >=20 > Background: > I think many people would agree that SDES has some benefits compared to > DTLS for those of us wishing to interface to the SIP world. Some of > those benefits are commercial/cost factors, some are more tangible like > reducing early media clipping. Whether you agree with such benefits or > not, so long as WebRTC could support SDES in a sufficiently-secure > manner, there'd be less concern over having it. Most of the arguments > against SDES have been directed at whether it could in fact be > "sufficiently secure". Personally I find most of the arguments against > it being secure enough to be essentially FUD, and/or also apply to > DTLS-SRTP. >=20 > On the flip-side, I think the commercial/cost factor for SDES is not a > strong cause, because I believe the market will bear whatever the extra > cost may be. (I wasn't sure of this 2 years ago when this all started, > but I'm fairly confident of it now) And I think having only DTLS-SRTP > as MTI would have a marketing benefit for WebRTC as a technology, which > I value highly. There is a significant cost factor in scenarios where a large percentage of= sessions have to be interworked and whether the market will bear this or n= ot it is certainly a cost that it would be good to avoid.=20 >=20 > Given those personal feelings, I didn't much care either way, so long > as a decision was made - although I still preferred having SDES to > avoid the early media clipping problem. So when I was going to present > on this topic back in the Vancouver meeting, my last slide basically > said: "If we support SDES and it turns out later we were wrong, we can > always rescind it". This was based on the notion that browsers get > updated all the time, especially for security issues. >=20 > But later it occurred to me that's actually the Achilles' heel of > supporting SDES in WebRTC, for those of us wanting to gateway this > stuff to SIP. Imagine if it turns out we were wrong, and some > expected-or-unexpected vulnerability is exploited against some large > WebRTC service provider, and makes the news/slashdot. Browser vendors > would instantly have new code removing SDES support, and browsers in > devices would be updated virtually overnight - some users may take a > long time to upgrade their specific browsers on their specific devices > - but many of them would do so within days. That would be untenable > for a WebRTC service provider. Even the smaller Enterprises take a > long time to upgrade code on their servers, so even for them changing > their gateways to suddenly support DTLS-SRTP would be unrealistic. > Imagine what it would be for larger providers, who might even have to > deploy more servers to handle the sudden additional overhead of DTLS- > SRTP. Meanwhile a growing perc > entage of their users can no longer use the service. That's bad mojo. >=20 > The things that a WebRTC-to-SIP service provider can control, and > arguably the much larger use-case for this stuff to begin with, are not > really true "browsers" anyway - they're web-based-framework device > Apps, provided by the service provider to begin with. I.e., the apps > they build using web application framework things like > PhoneGap/Cordova, Appcelerator Titanium, etc. I mean using a real > Browser is nice for ad-hoc stuff, like being able to click on a "talk > to a rep" button on a website, or a webex/meetecho type thing; but for > real communication "service", whether it be as a subscriber of a > traditional carrier, or Skype, or an employee of an Enterprise, or a > call-center attendant, or whatever - for those most people would never > want to have to open a browser just to receive/make calls. They'd give > you an app to use instead. >=20 > So it's the app use-case that would benefit the most from SDES, > especially for issues like media clipping. And the app use-case > doesn't have the security concerns nor concerns for unforeseen > overnight updates. >=20 > The Compromise: > So given that background, I was planning to propose that the security > doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a > statement that web-based application frameworks SHOULD also support > SDES. (with text about why and how, etc.) I don't think we can or should say that SDES SHOULD be implemented by one t= ype of framework but not another we just need to say something consistent f= or all. I agree with most of what is stated in the reasoning above and give= n that there is a strong commercial incentive for SDES support I think keep= ing DTLS-SRTP as the MTI and making SDES a SHOULD would be a good compromis= e.=20 >=20 > I don't think this is too controversial, because web-based frameworks > are never beholden to following browser behavior anyway - they're used > to build a native application, and native applications have a very > different security/threat model in practice. They're written for a > specific purpose, and installed by users from known sources for that > known purpose. Technically, afaik, nothing we do in RTCWEB WG or W3C's > WEBRTC group have any requirements/mandates for native applications > anyway - an app maker would just ignore something they don't think > applies to them - but I think web-based frameworks do generally try to > follow W3C models for Javascript APIs, and will likely read the IETF > RFCs for the media-layer stuff too. So I think having this SHOULD > statement would be beneficial. >=20 > Or if the WG prefers, we could even write a separate doc on what a web- > based framework maker should consider supporting/not-supporting. (I can > imagine a few other things they might want to offer that a browser > can't) >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Tue Jul 16 06:43:08 2013 Return-Path: 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 75D7121F85C3 for ; Tue, 16 Jul 2013 06:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.262 X-Spam-Level: X-Spam-Status: No, score=-5.262 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 SsOfVaG3YDLa for ; Tue, 16 Jul 2013 06:43:02 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6236021F85B4 for ; Tue, 16 Jul 2013 06:43:01 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-54-51e54de307de Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DD.2E.06741.3ED45E15; Tue, 16 Jul 2013 15:42:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Tue, 16 Jul 2013 15:42:59 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOeDFbTNRhHYI3NkSZeqhrbqmeQg== Date: Tue, 16 Jul 2013 13:42:58 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3157F7@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvre5j36eBBvO2GVhM32djMePCVGaL tf/a2R2YPc41vGf3WLLkJ5PHrSkFAcxRXDYpqTmZZalF+nYJXBlTT7cyFcwTrbjz6yB7A+Nf gS5GTg4JAROJXTePMUPYYhIX7q1n62Lk4hASOMwo8ebqc2YIZxGjxMmOpWwgVWwCgRJb9y0A s0UELCVuzL0JVMTBwSzgIzF3syJIWFigSmL54WPsIGERgWqJJf3lENV6El0Xt7KA2CwCqhJL rv8Gm8Ir4Cux8Nh0qFXHWCUu394DlmAEOuj7qTVMIDazgLjErSfzmSAOFZBYsuc81NGiEi8f /2OFsJUkGpc8YYWo15O4MXUKG4StLbFs4WtmiGWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEj yypG9tzEzJz0csNNjMDYOLjlt+4OxlPnRA4xSnOwKInzbtI7EygkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBsX8Ol7zCvvWnjp3l3jHvpIHDd05pnXKh2XduPgq+t23nN4GoPewTTr+o+rg3 8fiOrj3ZG8XWRyo6e69YcCfq1qvDr8s28mYLvPwbppzkazih60nrCXUGW3Vm5s9zXh3/kxng YnJ76SSH+jUKis/zkmQXWTZ/nnqjLddtz92+5JRc137O9xoTLiqxFGckGmoxFxUnAgD+yUiw WwIAAA== Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:43:08 -0000 On 7/8/13 10:43 PM, I=F1aki Baz Castillo wrote:=0A= > 2013/7/8 Stefan H=E5kansson LK :=0A= >>> So, was there ever a consensus that "developers MUST NOT=0A= >>> touch SDP"?=0A= >>=0A= >> No, developers are free to touch the SDP (and probably must in certain= =0A= >> cases).=0A= >=0A= >=0A= > Do you feel how much painful is "touching a browser generated SDP"? To be= clear:=0A= >=0A= > - JS requests "A" to browser.=0A= > - Browser returns "A" (in the form of unmanageable blob).=0A= > - JS modifies "A" to send "A-bis" in the wire.=0A= > - Remote peer receives "A-bis" and replies "B-bis".=0A= > - Both JS app are lying to their respective browsers to get the=0A= > desired behavior.=0A= >=0A= > This is really painful, really.=0A= =0A= I've been doing:=0A= =0A= - JS requests "A" to browser.=0A= - Browser returns "A" (in the form of unmanageable blob).=0A= - JS modifies "A" to send "A-bis" in the wire to a system not =0A= understanding "A" as is=0A= - Remote end receives "A-bis" and replies "B-bis".=0A= - JS modifies "B-bis" (using parts of "A" in the process) and applies =0A= "B" to browser=0A= =0A= Not nice and clean for sure, but quite doable. JS is nice for text parsing.= =0A= =0A= But the big problems I experienced were:=0A= * "A" was different between different browsers (in a way that the JS had = =0A= to be different)=0A= * "A" would change in ways breaking my code between versions=0A= * What would accepted for "B" would also vary.=0A= =0A= Most of this would presumable go away once we settle on exactly how SDP =0A= should be used (assuming SDP stays).=0A= =0A= But all that said, I still think we need API surface that makes the need = =0A= to mangle the SDP an exception (OTOH, perhaps interop with legacy - as I = =0A= did - is an exception? Depends on where you come from I guess.).=0A= =0A= >=0A= > In the other side, as I explained in other thread (may be in this=0A= > one?) adding some methods to the current API (to avoid playing with=0A= > the SDP) is not the way to go. A specification in which the JS app=0A= > does not know what he is sending in-the-wire (a blob generated by the=0A= > browser) is doomed to failure.=0A= >=0A= > Please remember that mandating SDP (plain SDP) means that no other=0A= > media signaling protocol can be implemented in future WebRTC apps.=0A= =0A= I think Peter Thatcher had an idea of an API extension where you could =0A= do away with SDP if you want to.=0A= =0A= >=0A= > SIP phones have *fixed* code and *fixed* logic. This is no longer true=0A= > in the Web.=0A= >=0A= > --=0A= > I=F1aki Baz Castillo=0A= > =0A= >=0A= =0A= From salvatore.loreto@ericsson.com Tue Jul 16 07:06:30 2013 Return-Path: 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 0541B21E804C for ; Tue, 16 Jul 2013 07:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 IC8LxDjEs7tJ for ; Tue, 16 Jul 2013 07:06:19 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E770F21E8050 for ; Tue, 16 Jul 2013 07:06:18 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-70-51e553596000 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 64.51.06741.95355E15; Tue, 16 Jul 2013 16:06:18 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.328.9; Tue, 16 Jul 2013 16:06:17 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4623111021C for ; Tue, 16 Jul 2013 17:06:17 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8195A556CB for ; Tue, 16 Jul 2013 17:06:13 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E8FC553AA3 for ; Tue, 16 Jul 2013 17:06:12 +0300 (EEST) Message-ID: <51E55357.7020300@ericsson.com> Date: Tue, 16 Jul 2013 16:06:15 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <9F33F40F6F2CD847824537F3C4E37DDF1164963D@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1164963D@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+JvrW5U8NNAg6Zd7BZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+OEk6wF5zkqzk/4xNrA+IGti5GTQ0LARKJvwxpGCFtM4sK9 9UBxLg4hgcOMEr/vrWaBcNYzSty4c5sJwrnMKPH53X1WkBYhgSOMEg+naUAkzjJKPN94kxkk wSugLbH+eB87iM0ioCrx5s5nJhCbTcBM4vnDLWA1ogLJEu+v3IGqF5Q4OfMJC4gtIiAq8frx NKAFHBzCQHM+nqyCmL+HSeLs4puMIHFOAX+JSZuDQMqZBWwlLsy5zgJhy0tsfzuHGeIdNYmr 5zYxQ9ypJdF7tpNpAqPILCTbZiFpn4WkfQEj8ypG9tzEzJz0csNNjMBQPrjlt+4OxlPnRA4x SnOwKInzbtI7EygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcaaeyQ2+NROnhF7ascttT1d2 BoP+w/TUfY/lH2gJFBZalykvvhx4rTCeYa/QZteLLe1iCkJrnXl8T5hxrkx71lDJ3jddcO6O qqoqZfOZic5zfHRypwXYva9VFalbcvP6rMyE6GpGU99pXv4zusL3fpqsZ73XXE0wXfP5OfvW zbGMJ5IPKBsqsRRnJBpqMRcVJwIAUKAJqDMCAAA= Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:06:30 -0000 On 7/16/13 3:22 PM, Hutton, Andrew wrote: >> The Compromise: >> >So given that background, I was planning to propose that the security >> >doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a >> >statement that web-based application frameworks SHOULD also support >> >SDES. (with text about why and how, etc.) > I don't think we can or should say that SDES SHOULD be implemented by one type of framework but not another we just need to say something consistent for all. I agree with most of what is stated in the reasoning above and given that there is a strong commercial incentive for SDES support I think keeping DTLS-SRTP as the MTI and making SDES a SHOULD would be a good compromise. > I also agree with most of what Hadriel stated in his long mail; however I don't like the idea we start to make difference between what kind of webrtc you can do with a browser and what you can do on a web-based application framework (btw I also share the Andrew concern about the fact that we can/should say what to do or not to do in each type of framework) /Salvatore From enrico.marocco@telecomitalia.it Tue Jul 16 07:35:34 2013 Return-Path: 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 0D80611E80DC for ; Tue, 16 Jul 2013 07:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.569 X-Spam-Level: X-Spam-Status: No, score=-101.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 K1xxC8wnwC6V for ; Tue, 16 Jul 2013 07:35:29 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id A2A2811E80EE for ; Tue, 16 Jul 2013 07:35:28 -0700 (PDT) Received: from grfhub701rm001.griffon.local (10.19.3.8) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 16 Jul 2013 16:35:27 +0200 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.234) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 16 Jul 2013 16:35:26 +0200 Message-ID: <51E55A2E.8090303@telecomitalia.it> Date: Tue, 16 Jul 2013 16:35:26 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060107060607000700050401" X-TI-Disclaimer: Disclaimer1 Subject: Re: [rtcweb] Some thoughts on optional audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:35:34 -0000 --------------ms060107060607000700050401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/15/13 5:15 PM, Bo Burman wrote: > In that draft, I would prefer something more in line with: >=20 > "If other suitable audio codecs are available to the browser to use, > it is recommended that they are also included in the offer in order > to maximize the possibility to establish the session without the need > for audio transcoding". Yes, in fact this is happening already: https://hacks.mozilla.org/2013/01/firefox-development-highlights-h-264-mp= 3-support-on-windows-scoped-stylesheets-more/ If people feel SHOULD/RECOMMENDED to be too strong, I'm sure we can find the right keyword in RFC 6919.. Enrico --------------ms060107060607000700050401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MTYx NDM1MjZaMCMGCSqGSIb3DQEJBDEWBBRHMYTzRzH1XNq0raDMiBHKgJhrNDBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAeCcrDExXGBaNlCsOeMRy5gzYotGOo7BU/g1vZSN/ zx4ji8Aq6VOpeMR7HupvUD73hGYjvJByvXChtd/j5R7TyaF25vustrBMqmIW9D/LJq7xRpIz Bs8bqRo6E7zw6pgUokhlrE6/FS1JDOPUGoYYC2gm8p2H5uLT1CyiirtUMXs6Y+asUWjCBUDW MFX4Ud6PJNldvaLMBvGd0H24Lw9BV6S2v21OZg50zBoBY3p0gMQpkPSyKsxlx2o9klFvDJoD jdJhpyUvck/LXPh/L9B0+tWQrizy4Ba1wXfvSfIG+YWEuXO0cih7kNyAChXr4qBpc83YZkII CqnijzEsr7toUgAAAAAAAA== --------------ms060107060607000700050401-- From keith.drage@alcatel-lucent.com Tue Jul 16 07:58:33 2013 Return-Path: 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 4D55521F9B8C; Tue, 16 Jul 2013 07:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 HsNPlcex7ima; Tue, 16 Jul 2013 07:58:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D14CA21F84D1; Tue, 16 Jul 2013 07:58:27 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6GEwPhL020697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jul 2013 09:58:27 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GEwP2U023868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 16:58:25 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 16:58:25 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" , "dispatch@ietf.org" , "avt@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrA Date: Tue, 16 Jul 2013 14:58:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06AD7A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [rtcweb] FW: Taxonomy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:58:33 -0000 Extensive cross-post do not reply to this email. For information. We do expect participation input from all the listed worki= ng groups (and possibly more). Keith -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= DRAGE, Keith (Keith) Sent: 16 July 2013 15:53 To: avtext@ietf.org Subject: [avtext] Taxonomy (As AVTEXT WG cochair) The latest version of the RTP taxonomy draft has been submitted. https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy= /=20 This document was allocated to AVTEXT by DISPATCH, and we have created a mi= lestone for it in AVTEXT. This draft is not yet a working group document. We do expect to spend some significant meeting time discussing the contents= in the AVTEXT meeting in Berlin, so please start raising your issues on th= e AVTEXT list. Additionally, if there are counter proposals existing that the AVTEXT chair= s would not otherwise be aware of, then please identify them to the AVTEXT = chairs / list. Regards Keith _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From Kalyani.Bogineni@VerizonWireless.com Tue Jul 16 10:02:27 2013 Return-Path: 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 8726021F9ABB for ; Tue, 16 Jul 2013 10:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 3ovJwaQvxdu7 for ; Tue, 16 Jul 2013 10:02:23 -0700 (PDT) Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id B5DD911E80D7 for ; Tue, 16 Jul 2013 10:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1373994143; x=1405530143; h=from:to:cc:date:subject:references:in-reply-to: content-transfer-encoding:mime-version; bh=3/DzSmu2DPtV44ANqWnkWN0NsTLbssSHDYs9lWfAP24=; b=eOISoYdzxpIAm1gSZL1Xugk0tjCLTmv1Dr9dUMFQPQ1rD7CTcw27daMD yctEZ0brtWzXH3dU5Cq4V4nH4yZjZZdgc/9DHes3/mi6rwZDi8RScP1Fe MfZxnDGab+CPTRp+xF7ymlU0/CPapMi+N2kHq4byxEh44zwHs9A2F4uaB g=; Received: from ohdub02exhub04.uswin.ad.vzwcorp.com ([10.97.42.166]) by vanguard.verizonwireless.com with ESMTP; 16 Jul 2013 10:02:13 -0700 Received: from OHDUB02EXCV33.uswin.ad.vzwcorp.com ([10.97.42.179]) by OHDUB02EXHUB04.uswin.ad.vzwcorp.com ([10.97.42.166]) with mapi; Tue, 16 Jul 2013 13:02:07 -0400 From: "Bogineni, Kalyani" To: 'Bo Burman' , "rtcweb@ietf.org" Date: Tue, 16 Jul 2013 13:02:07 -0400 Thread-Topic: Some thoughts on optional audio codecs Thread-Index: Ac6BN11IugiIgzm2TXug3PomYB8N3ABDXdRA References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: <20130716170223.B5DD911E80D7@ietfa.amsl.com> Cc: "Bogineni, Kalyani" Subject: Re: [rtcweb] Some thoughts on optional audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 17:02:27 -0000 We support the following wording proposal from Bo Burman. "If other suitable audio codecs are available to the browser to use, it is = recommended that they are also included in the offer in order to maximize t= he possibility to establish the session without the need for audio transcod= ing". Regards, Kalyani Bogineni Verizon -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bo Burman Sent: Monday, July 15, 2013 11:15 AM To: rtcweb@ietf.org Subject: [rtcweb] Some thoughts on optional audio codecs Regarding the previous discussion on optional audio codecs in the (currentl= y expired) draft on RTCWEB audio codecs (https://datatracker.ietf.org/doc/d= raft-ietf-rtcweb-audio/): I think most parties involved in WebRTC work, myself included, hope and bel= ieve that it will be ubiquitous and easy to include real-time media convers= ation functionality in nearly any web context. Since it will be that easy, = it can be expected that most web developers need not be, and thus will not = be, media specialists or very knowledgeable about codecs. The definition of RTCWEB MTI codecs ensures that communication is possible = since at least one codec will always be found, but it is not possible to cl= aim the resulting communication to be optimum for every possible context. Even if WebRTC will be close to ubiquitous, there will for quite some time = likely be a desire to reach real-time media domains and devices that were n= ot originally designed for and thus are not optimized for use with WebRTC. = A communication device that is not designed solely for WebRTC use will like= ly include functionality and codecs also for its "native" domain. Any added cost of not being able to use existing "native" codecs will vary = both in amount and where the cost has to be taken. Eliminating it is indeed= an optimization, but the total cost savings may still be significant. With the current design and to my understanding, it will be the browser ven= dor's choice to add optional codecs, including any "native" domain codecs. = The choice may possibly be delegated to individual web developers making u= se of WebRTC functionality. A browser vendor will arguably have to know eac= h target platform to some extent, but it can hardly be assumed that a web d= eveloper knows the capabilities of all devices that will use the WebRTC-ena= bled site unless the browser can provide the needed information. There is a= risk that "native" codecs in devices are not well handled, unless the moti= vations and methods to make use of them are better specified. While any audio codecs besides the MTI ones are clearly optional, I believe= the suggested text addition on optional audio codecs to the RTCWEB audio d= raft in Ticket #12 (http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12#) t= o be too brief considering the above. In that draft, I would prefer something more in line with: "If other suitable audio codecs are available to the browser to use, it is = recommended that they are also included in the offer in order to maximize t= he possibility to establish the session without the need for audio transcod= ing". Assuming that the browser vendor (or web developer) is sufficiently concern= ed with codecs to read the audio codecs draft (or the corresponding RFC to-= be), the above text may, as a start, give some added guidance why non-MTI c= odecs may be desirable to consider in addition to the MTI ones. Cheers, Bo Multimedia Technologies Ericsson Research F=E4r=F6gatan 6 SE-164 80, Kista, Sweden www.ericsson.com _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From adam@nostrum.com Tue Jul 16 13:07:19 2013 Return-Path: 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 9139521F9DCF for ; Tue, 16 Jul 2013 13:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 FQaebVqVZbhR for ; Tue, 16 Jul 2013 13:07:18 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7E14721F9EE9 for ; Tue, 16 Jul 2013 13:07:18 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6GK7550005445 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 15:07:07 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E5A7E4.5020408@nostrum.com> Date: Tue, 16 Jul 2013 15:07:00 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Enrico Marocco References: <51E55A2E.8090303@telecomitalia.it> In-Reply-To: <51E55A2E.8090303@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Some thoughts on optional audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:07:19 -0000 On 7/16/13 09:35, Enrico Marocco wrote: > On 7/15/13 5:15 PM, Bo Burman wrote: >> In that draft, I would prefer something more in line with: >> >> "If other suitable audio codecs are available to the browser to use, >> it is recommended that they are also included in the offer in order >> to maximize the possibility to establish the session without the need >> for audio transcoding". > Yes, in fact this is happening already: > https://hacks.mozilla.org/2013/01/firefox-development-highlights-h-264-mp3-support-on-windows-scoped-stylesheets-more/ > You have misread that article. What that article says is that Mozilla is adding select platform-supplied codecs to Firefox for non-WebRTC uses. Our implementation of audio codecs for WebRTC continues to support PCMU, PCMA, Opus, and nothing else; our implementation use VP8 exclusively for video. /a From bernard_aboba@hotmail.com Tue Jul 16 17:15:51 2013 Return-Path: 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 21A9A21F9CF1 for ; Tue, 16 Jul 2013 17:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 4cJby-12R344 for ; Tue, 16 Jul 2013 17:15:46 -0700 (PDT) Received: from blu0-omc1-s30.blu0.hotmail.com (blu0-omc1-s30.blu0.hotmail.com [65.55.116.41]) by ietfa.amsl.com (Postfix) with ESMTP id 02F5D21F9CAF for ; Tue, 16 Jul 2013 17:15:45 -0700 (PDT) Received: from BLU401-EAS386 ([65.55.116.8]) by blu0-omc1-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 17:15:46 -0700 X-TMN: [vt/30MiTDlEZcLXV950NeHmuGMzdI6m5] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> Date: Tue, 16 Jul 2013 17:15:40 -0700 To: =?utf-8?Q?Stefan_H=C3=A5kansson_LK?= X-OriginalArrivalTime: 17 Jul 2013 00:15:46.0135 (UTC) FILETIME=[C87D7E70:01CE8282] Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 00:15:51 -0000 VGhlIHByb2JsZW0gd2FzIHRoYXQgd2UgbmV2ZXIgZGVmaW5lZCB3aGF0IG1hbmdsaW5nIGJyb3dz ZXJzIGhhZCB0byBzdXBwb3J0LiBHaXZlbiBhbGwgdGhlIFNEUCBzcGVjcyB0aGF0IGlzIGFjdHVh bGx5IGEgaHVnZSB3b3JrIGl0ZW0uIEFuZCBjcmVhdGluZyBBUElzIHRvIGF2b2lkIG1hbmdsaW5n IGlzbid0IGFjdHVhbGx5IHRoYXQgbXVjaCBzaW1wbGVyLiBXaGF0IGtub2JzIGRvIHlvdSBwcm92 aWRlIGFuZCB3aGljaCBvbmVzIGRvIHlvdSBpZ25vcmU/IEJyb3dzZXJzIG1pZ2h0IG5vdCBhZ3Jl ZSBvbiB0aG9zZSBlaXRoZXIuDQoNCk9uIEp1bCA4LCAyMDEzLCBhdCAxOjM3IFBNLCAiU3RlZmFu IEjDpWthbnNzb24gTEsiIDxzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbT4gd3JvdGU6 DQoNCj4gT24gNy84LzEzIDU6MjIgUE0sIFJvbWFuIFNocG91bnQgd3JvdGU6DQo+IA0KPj4gU28s IHdhcyB0aGVyZSBldmVyIGEgY29uc2Vuc3VzIHRoYXQgImRldmVsb3BlcnMgTVVTVCBOT1QNCj4+ IHRvdWNoIFNEUCI/DQo+IA0KPiBObywgZGV2ZWxvcGVycyBhcmUgZnJlZSB0byB0b3VjaCB0aGUg U0RQIChhbmQgcHJvYmFibHkgbXVzdCBpbiBjZXJ0YWluIA0KPiBjYXNlcykuDQo+IA0KPj4gDQo+ PiBfX19fX19fX19fX19fDQo+PiBSb21hbiBTaHBvdW50DQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J0Y3dlYg0K From silviapfeiffer1@gmail.com Tue Jul 16 17:27:08 2013 Return-Path: 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 EC82F21F9D87 for ; Tue, 16 Jul 2013 17:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HniBlqWg+++N for ; Tue, 16 Jul 2013 17:27:06 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4989C21F9D7E for ; Tue, 16 Jul 2013 17:27:06 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l10so1688424oag.17 for ; Tue, 16 Jul 2013 17:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=gS1Nv3cLQ9kbuztOGhTG9CT9A/WVrw2poFz2Q6FOC0g=; b=LfZoHeRMTEs3NKH1xPzeRO80BQV/liXtfWcfxsFiyCeWSJnx3CXbL7lweCyoa301zX S69bnEDpXVRfl8ooM0lClxwPlNdR4RG24ziPrfJII5WhyiTvLHHXzlMf0nxOzP/AoZEC dXXm63K1M1ltWeb5Qd6IV3lL6OVySi2RKuG/9HEIrf8OIt/TMdu+D7NIwNuhRsUAQ7MB 3DSvjmuaYiMY1VNvZyB9KfH10IcnrhsQoQZizIndJXLR0Qb1UsRvJJtnCoFdqkokQ+zw uczDNmqSzYqchhbqiJrDsOh7ETHoje+f/XTuAgxJ0KZDuZY1HPyK8H2Va5eUZPJVmE/n xK3w== X-Received: by 10.60.95.198 with SMTP id dm6mr5172837oeb.44.1374020825390; Tue, 16 Jul 2013 17:27:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.173.106 with HTTP; Tue, 16 Jul 2013 17:26:45 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> From: Silvia Pfeiffer Date: Wed, 17 Jul 2013 10:26:45 +1000 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 00:27:08 -0000 The whole point of standardisation at the W3C is for browser to agree on the knobs. So, I do think it's a valuable effort. Cheers, Silvia. On Wed, Jul 17, 2013 at 10:15 AM, Bernard Aboba wrote: > The problem was that we never defined what mangling browsers had to suppo= rt. Given all the SDP specs that is actually a huge work item. And creating= APIs to avoid mangling isn't actually that much simpler. What knobs do you= provide and which ones do you ignore? Browsers might not agree on those ei= ther. > > On Jul 8, 2013, at 1:37 PM, "Stefan H=E5kansson LK" wrote: > >> On 7/8/13 5:22 PM, Roman Shpount wrote: >> >>> So, was there ever a consensus that "developers MUST NOT >>> touch SDP"? >> >> No, developers are free to touch the SDP (and probably must in certain >> cases). >> >>> >>> _____________ >>> Roman Shpount >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Tue Jul 16 17:30:43 2013 Return-Path: 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 70BA321F9D02 for ; Tue, 16 Jul 2013 17:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 g0nbnrNAt3tg for ; Tue, 16 Jul 2013 17:30:38 -0700 (PDT) Received: from blu0-omc3-s25.blu0.hotmail.com (blu0-omc3-s25.blu0.hotmail.com [65.55.116.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4823921F8EC3 for ; Tue, 16 Jul 2013 17:30:38 -0700 (PDT) Received: from BLU403-EAS140 ([65.55.116.74]) by blu0-omc3-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 17:30:37 -0700 X-TMN: [uJerD6IQU05Nos1iEmyyjPaXYaSTExKD] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Tue, 16 Jul 2013 17:30:28 -0700 To: Silvia Pfeiffer X-OriginalArrivalTime: 17 Jul 2013 00:30:37.0717 (UTC) FILETIME=[DBEA1C50:01CE8284] Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 00:30:43 -0000 SSB3b3VsZCBhZ3JlZS4gSnVzdCBwb2ludGluZyBvdXQgdGhhdCB0aGlzIGlzc3VlIHdhcyByYWlz ZWQgaW4gRGVjZW1iZXIgMjAxMiwgYW5kIGl0IGlzIG5vdyA2KyBtb250aHMgbGF0ZXIgd2l0aCBs aXR0bGUgcHJvZ3Jlc3MgYW5kIG1vcmUgZGlzZ3J1bnRsZW1lbnQuIFNvIGlmIHRoZXJlIGlzIG1v dGl2YXRpb24gdG8gZml4IHRoaXMgaXQgcHJvYmFibHkgd291bGQgaGF2ZSBtYW5pZmVzdGVkIGl0 c2VsZiBieSBub3cuIA0KDQpPbiBKdWwgMTYsIDIwMTMsIGF0IDU6MjcgUE0sICJTaWx2aWEgUGZl aWZmZXIiIDxzaWx2aWFwZmVpZmZlcjFAZ21haWwuY29tPiB3cm90ZToNCg0KPiBUaGUgd2hvbGUg cG9pbnQgb2Ygc3RhbmRhcmRpc2F0aW9uIGF0IHRoZSBXM0MgaXMgZm9yIGJyb3dzZXIgdG8gYWdy ZWUNCj4gb24gdGhlIGtub2JzLiBTbywgSSBkbyB0aGluayBpdCdzIGEgdmFsdWFibGUgZWZmb3J0 Lg0KPiBDaGVlcnMsDQo+IFNpbHZpYS4NCj4gDQo+IA0KPiBPbiBXZWQsIEp1bCAxNywgMjAxMyBh dCAxMDoxNSBBTSwgQmVybmFyZCBBYm9iYQ0KPiA8YmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbT4g d3JvdGU6DQo+PiBUaGUgcHJvYmxlbSB3YXMgdGhhdCB3ZSBuZXZlciBkZWZpbmVkIHdoYXQgbWFu Z2xpbmcgYnJvd3NlcnMgaGFkIHRvIHN1cHBvcnQuIEdpdmVuIGFsbCB0aGUgU0RQIHNwZWNzIHRo YXQgaXMgYWN0dWFsbHkgYSBodWdlIHdvcmsgaXRlbS4gQW5kIGNyZWF0aW5nIEFQSXMgdG8gYXZv aWQgbWFuZ2xpbmcgaXNuJ3QgYWN0dWFsbHkgdGhhdCBtdWNoIHNpbXBsZXIuIFdoYXQga25vYnMg ZG8geW91IHByb3ZpZGUgYW5kIHdoaWNoIG9uZXMgZG8geW91IGlnbm9yZT8gQnJvd3NlcnMgbWln aHQgbm90IGFncmVlIG9uIHRob3NlIGVpdGhlci4NCj4+IA0KPj4gT24gSnVsIDgsIDIwMTMsIGF0 IDE6MzcgUE0sICJTdGVmYW4gSMOla2Fuc3NvbiBMSyIgPHN0ZWZhbi5say5oYWthbnNzb25AZXJp Y3Nzb24uY29tPiB3cm90ZToNCj4+IA0KPj4+IE9uIDcvOC8xMyA1OjIyIFBNLCBSb21hbiBTaHBv dW50IHdyb3RlOg0KPj4+IA0KPj4+PiBTbywgd2FzIHRoZXJlIGV2ZXIgYSBjb25zZW5zdXMgdGhh dCAiZGV2ZWxvcGVycyBNVVNUIE5PVA0KPj4+PiB0b3VjaCBTRFAiPw0KPj4+IA0KPj4+IE5vLCBk ZXZlbG9wZXJzIGFyZSBmcmVlIHRvIHRvdWNoIHRoZSBTRFAgKGFuZCBwcm9iYWJseSBtdXN0IGlu IGNlcnRhaW4NCj4+PiBjYXNlcykuDQo+Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fDQo+ Pj4+IFJvbWFuIFNocG91bnQNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+PiBydGN3ZWJA aWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl Yg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From ranjit.avasarala@nsn.com Tue Jul 16 22:50:58 2013 Return-Path: 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 2FC5221F9D7E; Tue, 16 Jul 2013 22:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 B+z7keczTavn; Tue, 16 Jul 2013 22:50:53 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id F225D21F9D75; Tue, 16 Jul 2013 22:50:51 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6H5okNv000695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 07:50:46 +0200 Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6H5oYFP019158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 07:50:45 +0200 Received: from SGSIHTC008.nsn-intra.net (10.159.225.25) by SGSIHTC002.nsn-intra.net (10.159.225.19) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Jul 2013 13:48:52 +0800 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.242]) by SGSIHTC008.nsn-intra.net ([10.159.225.25]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 13:48:52 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: "Muthu Arul Mozhi Perumal (mperumal)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjA Date: Wed, 17 Jul 2013 05:48:51 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: <51E544BC.6000608@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3795 X-purgate-ID: 151667::1374040247-00002EAE-9CF423F9/0-0/0-0 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 05:50:58 -0000 Hi Muthu Though using STUN request/response may be good for querying about consent, = I feel it is overloading the functionality of STUN. Many publicly available= STUN servers or those that are part of Call servers may not support this. Can't there be some other neutral mechanism to query peer's consent - throu= gh signaling?=20 Regards Ranjit -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= ext Simon Perreault Sent: Tuesday, July 16, 2013 6:34 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: rtcweb@ietf.org; behave@ietf.org Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-f= reshness-04.txt Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : > |> |> Liveness timer: If no packets have been received on the local po= rt in > |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that > |> |> connectivity has been lost. The JavaScript application will use= this > |> |> notification however it desires (e.g., cease transmitting to the > |> |> remote peer, provide a notification to the user, etc.). > |> | > |> |This seems to me like it will not fulfill the goal set in the abstrac= t: > |> |"to ensure that a malicious JavaScript cannot use the browser as a > |> |platform for launching attacks". If the JavaScript is free to ignore = the > |> |notification from the browser, then it has no security benefits. If y= ou > |> |want to reach that goal, the browser needs to forcefully stop transmi= tting. > |> > |> That goal is fulfilled by the consent checks -- the browser would stop= transmitting everything on > |that candidate pair, including liveness checks, if there is a consent fa= ilure. > | > |That's not what the draft says. It says that the browser "notifies" the > |JS app. It needs to say that the browser MUST stop sending. >=20 > No. That section is about liveness check and its intention is just notify= the JavaScript of a potential connectivity loss. It is when the consent ch= eck fails the browser actually stops sending everything. Does the draft nee= d more text on the distinction between consent and liveness tests? Ah! No, you're right, and the text is already perfectly clear about this. No need to change. I was just confused. > |> |> When not actively sending traffic on a nominated candidate pair, > |> |> performing consent freshness does not serve any purpose from a > |> |> security perspective. > |> | > |> |I don't understand what this means. Why is the "security perspective" > |> |important here? Aren't we concerned about keepalives? > |> > |> You mean one could use keepalives (Binding indications) for launching = attacks, so consent freshness > |would be required for sending them as well? > | > |No. > | > |This is a section about keepalives. I just don't understand this > |sentence, and I don't understand why it talks about security. >=20 > Ok, let me elaborate: > - Consent freshness is not necessary when the browser is not sending any= =20 > traffic on a candidate pair. > - If the browser is not performing consent freshness on a candidate pair= =20 > for the above reason, it performs ICE keepalives (or RTP keepalives) to > refresh NAT bindings. >=20 > Of course, the browser could continue performing consent freshness even w= hen it is not sending any other traffic on that candidate pair and skip ICE= keepalives. Ah, ok I understand with your explanation. It makes sense. There should be a way to reformulate the text to make it clearer. Thanks, Simon _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From mperumal@cisco.com Tue Jul 16 23:37:22 2013 Return-Path: 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 1339221F9D4A; Tue, 16 Jul 2013 23:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.427 X-Spam-Level: X-Spam-Status: No, score=-10.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 iFYc2UfNHoHx; Tue, 16 Jul 2013 23:37:16 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A770B21F9D12; Tue, 16 Jul 2013 23:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4666; q=dns/txt; s=iport; t=1374043036; x=1375252636; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kacILdAJAaZOItV8uLV5qERGnmYWwob0yAqANn1IcBQ=; b=duMAhSoKL7YIQDDyswPKg9arZko5YKT9uT7+Zpi7/BnuvvJ7wNHf8Epn 1VuW2/rOtldq/UmAf8Y9650mpUBx03mF1ZXxBNu1G/Z4wo7xUqdRbHV2G P80yHTitBknLxZTYmMEB/08wKET5XxtiyjCTeKrpczvlNMetoTwmZOASR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAPQ55lGtJXG8/2dsb2JhbABagwY0T8IygQ0WdIIjAQEBBAEBAWsLDAQCAQgRBAEBCx0HJwsUCAEIAgQOBQiICAy1YwSPPTEHBoMGbgOIb6A6gVmBOYIo X-IronPort-AV: E=Sophos;i="4.89,682,1367971200"; d="scan'208";a="235793175" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jul 2013 06:37:15 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6H6bFL9002810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 06:37:15 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 01:37:15 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Avasarala, Ranjit (NSN - IN/Bangalore)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoA= Date: Wed, 17 Jul 2013 06:37:15 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.222] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 06:37:22 -0000 Ranjit, |Many publicly available STUN servers or those that are part of Call server= s |may not support this. Public STUN servers and call servers are not expected to support this. |Can't there be some other neutral mechanism to query peer's consent - thro= ugh=20 |signaling? No. That signaling between the JS and the web server could be anything (SIP= or XMPP or proprietary or whatever) and the browser has no control over it= . Muthu |-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.= com] |Sent: Wednesday, July 17, 2013 11:19 AM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org; behave@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Hi Muthu | |Though using STUN request/response may be good for querying about consent,= I feel it is overloading |the functionality of STUN. Many publicly available STUN servers or those t= hat are part of Call servers |may not support this. | |Can't there be some other neutral mechanism to query peer's consent - thro= ugh signaling? | | |Regards |Ranjit | | | |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f ext Simon Perreault |Sent: Tuesday, July 16, 2013 6:34 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org; behave@ietf.org |Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |> |> |> Liveness timer: If no packets have been received on the local p= ort in |> |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that |> |> |> connectivity has been lost. The JavaScript application will us= e this |> |> |> notification however it desires (e.g., cease transmitting to th= e |> |> |> remote peer, provide a notification to the user, etc.). |> |> | |> |> |This seems to me like it will not fulfill the goal set in the abstra= ct: |> |> |"to ensure that a malicious JavaScript cannot use the browser as a |> |> |platform for launching attacks". If the JavaScript is free to ignore= the |> |> |notification from the browser, then it has no security benefits. If = you |> |> |want to reach that goal, the browser needs to forcefully stop transm= itting. |> |> |> |> That goal is fulfilled by the consent checks -- the browser would sto= p transmitting everything on |> |that candidate pair, including liveness checks, if there is a consent f= ailure. |> | |> |That's not what the draft says. It says that the browser "notifies" the |> |JS app. It needs to say that the browser MUST stop sending. |> |> No. That section is about liveness check and its intention is just notif= y the JavaScript of a |potential connectivity loss. It is when the consent check fails the browse= r actually stops sending |everything. Does the draft need more text on the distinction between conse= nt and liveness tests? | |Ah! No, you're right, and the text is already perfectly clear about |this. No need to change. I was just confused. | |> |> |> When not actively sending traffic on a nominated candidate pair= , |> |> |> performing consent freshness does not serve any purpose from a |> |> |> security perspective. |> |> | |> |> |I don't understand what this means. Why is the "security perspective= " |> |> |important here? Aren't we concerned about keepalives? |> |> |> |> You mean one could use keepalives (Binding indications) for launching= attacks, so consent |freshness |> |would be required for sending them as well? |> | |> |No. |> | |> |This is a section about keepalives. I just don't understand this |> |sentence, and I don't understand why it talks about security. |> |> Ok, let me elaborate: |> - Consent freshness is not necessary when the browser is not sending any |> traffic on a candidate pair. |> - If the browser is not performing consent freshness on a candidate pair |> for the above reason, it performs ICE keepalives (or RTP keepalives) t= o |> refresh NAT bindings. |> |> Of course, the browser could continue performing consent freshness even = when it is not sending any |other traffic on that candidate pair and skip ICE keepalives. | |Ah, ok I understand with your explanation. It makes sense. There should |be a way to reformulate the text to make it clearer. | |Thanks, |Simon |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From ranjit.avasarala@nsn.com Tue Jul 16 23:47:08 2013 Return-Path: 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 62B5C21F9D98 for ; Tue, 16 Jul 2013 23:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 UHd9i-xCyv3I for ; Tue, 16 Jul 2013 23:47:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5B31121F9D75 for ; Tue, 16 Jul 2013 23:47:03 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6H6kmvU019584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 08:46:49 +0200 Received: from SGSIHTC001.nsn-intra.net ([10.159.225.18]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6H6kZ5R013710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 08:46:48 +0200 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.242]) by SGSIHTC001.nsn-intra.net ([10.159.225.18]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 14:46:07 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: "ext Muthu Arul Mozhi Perumal (mperumal)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoCAAAceUA== Date: Wed, 17 Jul 2013 06:46:06 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5351 X-purgate-ID: 151667::1374043613-00002EAE-3F062F31/0-0/0-0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 06:47:08 -0000 Hi Muthu If many public STUN servers and call servers that implement STUN or ICElite= functionalities, are not expected to support, then who would have interest= to support this functionality? Ideally getting consent for receiving traff= ic or call should be part of signaling. I do not think using STUN is approp= riate. Regards Ranjit -----Original Message----- From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Sent: Wednesday, July 17, 2013 12:07 PM To: Avasarala, Ranjit (NSN - IN/Bangalore) Cc: rtcweb@ietf.org; behave@ietf.org Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-f= reshness-04.txt Ranjit, |Many publicly available STUN servers or those that are part of Call server= s |may not support this. Public STUN servers and call servers are not expected to support this. |Can't there be some other neutral mechanism to query peer's consent - thro= ugh=20 |signaling? No. That signaling between the JS and the web server could be anything (SIP= or XMPP or proprietary or whatever) and the browser has no control over it= . Muthu |-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.= com] |Sent: Wednesday, July 17, 2013 11:19 AM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org; behave@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Hi Muthu | |Though using STUN request/response may be good for querying about consent,= I feel it is overloading |the functionality of STUN. Many publicly available STUN servers or those t= hat are part of Call servers |may not support this. | |Can't there be some other neutral mechanism to query peer's consent - thro= ugh signaling? | | |Regards |Ranjit | | | |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f ext Simon Perreault |Sent: Tuesday, July 16, 2013 6:34 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org; behave@ietf.org |Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |> |> |> Liveness timer: If no packets have been received on the local p= ort in |> |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that |> |> |> connectivity has been lost. The JavaScript application will us= e this |> |> |> notification however it desires (e.g., cease transmitting to th= e |> |> |> remote peer, provide a notification to the user, etc.). |> |> | |> |> |This seems to me like it will not fulfill the goal set in the abstra= ct: |> |> |"to ensure that a malicious JavaScript cannot use the browser as a |> |> |platform for launching attacks". If the JavaScript is free to ignore= the |> |> |notification from the browser, then it has no security benefits. If = you |> |> |want to reach that goal, the browser needs to forcefully stop transm= itting. |> |> |> |> That goal is fulfilled by the consent checks -- the browser would sto= p transmitting everything on |> |that candidate pair, including liveness checks, if there is a consent f= ailure. |> | |> |That's not what the draft says. It says that the browser "notifies" the |> |JS app. It needs to say that the browser MUST stop sending. |> |> No. That section is about liveness check and its intention is just notif= y the JavaScript of a |potential connectivity loss. It is when the consent check fails the browse= r actually stops sending |everything. Does the draft need more text on the distinction between conse= nt and liveness tests? | |Ah! No, you're right, and the text is already perfectly clear about |this. No need to change. I was just confused. | |> |> |> When not actively sending traffic on a nominated candidate pair= , |> |> |> performing consent freshness does not serve any purpose from a |> |> |> security perspective. |> |> | |> |> |I don't understand what this means. Why is the "security perspective= " |> |> |important here? Aren't we concerned about keepalives? |> |> |> |> You mean one could use keepalives (Binding indications) for launching= attacks, so consent |freshness |> |would be required for sending them as well? |> | |> |No. |> | |> |This is a section about keepalives. I just don't understand this |> |sentence, and I don't understand why it talks about security. |> |> Ok, let me elaborate: |> - Consent freshness is not necessary when the browser is not sending any |> traffic on a candidate pair. |> - If the browser is not performing consent freshness on a candidate pair |> for the above reason, it performs ICE keepalives (or RTP keepalives) t= o |> refresh NAT bindings. |> |> Of course, the browser could continue performing consent freshness even = when it is not sending any |other traffic on that candidate pair and skip ICE keepalives. | |Ah, ok I understand with your explanation. It makes sense. There should |be a way to reformulate the text to make it clearer. | |Thanks, |Simon |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From enrico.marocco@telecomitalia.it Wed Jul 17 00:44:54 2013 Return-Path: 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 5DC2221F88DB for ; Wed, 17 Jul 2013 00:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.619 X-Spam-Level: X-Spam-Status: No, score=-101.619 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 969U3RNcKKgQ for ; Wed, 17 Jul 2013 00:44:49 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id DB93221F8C3E for ; Wed, 17 Jul 2013 00:44:48 -0700 (PDT) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 17 Jul 2013 09:44:44 +0200 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 17 Jul 2013 09:44:44 +0200 Message-ID: <51E64B6B.8080407@telecomitalia.it> Date: Wed, 17 Jul 2013 09:44:43 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Roach References: <51E55A2E.8090303@telecomitalia.it> <51E5A7E4.5020408@nostrum.com> In-Reply-To: <51E5A7E4.5020408@nostrum.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070901030702060503060000" X-TI-Disclaimer: Disclaimer1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Some thoughts on optional audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 07:44:54 -0000 --------------ms070901030702060503060000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/16/13 10:07 PM, Adam Roach wrote: >>> In that draft, I would prefer something more in line with: >>> >>> "If other suitable audio codecs are available to the browser to use, >>> it is recommended that they are also included in the offer in order >>> to maximize the possibility to establish the session without the need= >>> for audio transcoding". >> Yes, in fact this is happening already: >> https://hacks.mozilla.org/2013/01/firefox-development-highlights-h-264= -mp3-support-on-windows-scoped-stylesheets-more/ >=20 > You have misread that article. What that article says is that Mozilla i= s=20 > adding select platform-supplied codecs to Firefox for non-WebRTC uses. Sure, didn't mean to imply that it is happening for WebRTC. > Our implementation of audio codecs for WebRTC continues to support PCMU= ,=20 > PCMA, Opus, and nothing else; our implementation use VP8 exclusively fo= r=20 > video. And that's pretty visible also from the outside. What's not visible is whether at some point in time Mozilla will consider taking advantage of OS/platform-provided encoding/decoding capabilities also for WebRTC. One may be led to assume yes, as you're doing it for static content already. But maybe different conditions apply here, and I don't expect them to be discussed on this mailing list (even if it would be very, very interesting!). Enrico --------------ms070901030702060503060000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MTcw NzQ0NDNaMCMGCSqGSIb3DQEJBDEWBBT0nBhWJvojGBMH7zEY7yIHmZN3fzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAEpk8Dv+quQzhPNC5B743COI7lk8ICOsFWIiUzkjK WdZHPplCgi7y0hD824vuF6x+ry5+YI991meo9FMDkTolBb5LpPhn0eVw28YMEx8AG3d4kFVo lCh4Irflnbvc9F3yjV18o+xDXz9OtTflIKjzV+nNM7hJMAAlmucqtMvWkLGLyg9a9lVvRUQQ jS6lHrGQrqCfnksgwojyMMSYT65nIJSkcQfv8faxyPUsVNZ979O6sUeZqEjMUooFyng23Z7B DdZ3KFutOMsIa7N6p2mWwlQW21FQPjrprL8yIAyAAaovRN6qG6MuCe7kUurDf+4MpkHSYBdg NnRMNFNONc2OOQAAAAAAAA== --------------ms070901030702060503060000-- From andrew.hutton@siemens-enterprise.com Wed Jul 17 01:46:01 2013 Return-Path: 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 723F421F9955 for ; Wed, 17 Jul 2013 01:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 Z6LaMRUwZKo2 for ; Wed, 17 Jul 2013 01:45:57 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 09C9D21F9D1C for ; Wed, 17 Jul 2013 01:45:51 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C57EB1EB868D; Wed, 17 Jul 2013 10:45:47 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 10:45:47 +0200 From: "Hutton, Andrew" To: "Bogineni, Kalyani" , 'Bo Burman' , "rtcweb@ietf.org" Thread-Topic: Some thoughts on optional audio codecs Thread-Index: Ac6BN11IugiIgzm2TXug3PomYB8N3ABDXdRAACEuDYA= Date: Wed, 17 Jul 2013 08:45:47 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1164B89C@MCHP04MSX.global-ad.net> References: <20130716170223.B5DD911E80D7@ietfa.amsl.com> In-Reply-To: <20130716170223.B5DD911E80D7@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] Some thoughts on optional audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 08:46:01 -0000 We appear to have been around this loop a number of times the text suggeste= d here is exactly what was suggested by Andrew Allen back in January and I = for one supported it them and still do - See http://www.ietf.org/mail-archi= ve/web/rtcweb/current/msg06121.html. Not sure there was a definitive conclusion to that particular consensus cal= l. Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Bogineni, Kalyani > Sent: 16 July 2013 18:02 > To: 'Bo Burman'; rtcweb@ietf.org > Cc: Bogineni, Kalyani > Subject: Re: [rtcweb] Some thoughts on optional audio codecs >=20 > We support the following wording proposal from Bo Burman. >=20 > "If other suitable audio codecs are available to the browser to use, it > is recommended that they are also included in the offer in order to > maximize the possibility to establish the session without the need for > audio transcoding". >=20 > Regards, > Kalyani Bogineni > Verizon >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Bo Burman > Sent: Monday, July 15, 2013 11:15 AM > To: rtcweb@ietf.org > Subject: [rtcweb] Some thoughts on optional audio codecs >=20 > Regarding the previous discussion on optional audio codecs in the > (currently expired) draft on RTCWEB audio codecs > (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/): >=20 > I think most parties involved in WebRTC work, myself included, hope and > believe that it will be ubiquitous and easy to include real-time media > conversation functionality in nearly any web context. Since it will be > that easy, it can be expected that most web developers need not be, and > thus will not be, media specialists or very knowledgeable about codecs. >=20 > The definition of RTCWEB MTI codecs ensures that communication is > possible since at least one codec will always be found, but it is not > possible to claim the resulting communication to be optimum for every > possible context. >=20 > Even if WebRTC will be close to ubiquitous, there will for quite some > time likely be a desire to reach real-time media domains and devices > that were not originally designed for and thus are not optimized for > use with WebRTC. A communication device that is not designed solely for > WebRTC use will likely include functionality and codecs also for its > "native" domain. >=20 > Any added cost of not being able to use existing "native" codecs will > vary both in amount and where the cost has to be taken. Eliminating it > is indeed an optimization, but the total cost savings may still be > significant. >=20 > With the current design and to my understanding, it will be the browser > vendor's choice to add optional codecs, including any "native" domain > codecs. The choice may possibly be delegated to individual web > developers making use of WebRTC functionality. A browser vendor will > arguably have to know each target platform to some extent, but it can > hardly be assumed that a web developer knows the capabilities of all > devices that will use the WebRTC-enabled site unless the browser can > provide the needed information. There is a risk that "native" codecs in > devices are not well handled, unless the motivations and methods to > make use of them are better specified. >=20 > While any audio codecs besides the MTI ones are clearly optional, I > believe the suggested text addition on optional audio codecs to the > RTCWEB audio draft in Ticket #12 > (http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12#) to be too brief > considering the above. >=20 > In that draft, I would prefer something more in line with: >=20 > "If other suitable audio codecs are available to the browser to use, it > is recommended that they are also included in the offer in order to > maximize the possibility to establish the session without the need for > audio transcoding". >=20 > Assuming that the browser vendor (or web developer) is sufficiently > concerned with codecs to read the audio codecs draft (or the > corresponding RFC to-be), the above text may, as a start, give some > added guidance why non-MTI codecs may be desirable to consider in > addition to the MTI ones. >=20 > Cheers, > Bo >=20 > Multimedia Technologies > Ericsson Research > F=E4r=F6gatan 6 > SE-164 80, Kista, Sweden > www.ericsson.com > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From mperumal@cisco.com Wed Jul 17 01:46:13 2013 Return-Path: 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 833E021F9D87 for ; Wed, 17 Jul 2013 01:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 iXXoS0ELQuTS for ; Wed, 17 Jul 2013 01:46:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EC58F21F9D2C for ; Wed, 17 Jul 2013 01:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6628; q=dns/txt; s=iport; t=1374050765; x=1375260365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=l2Y4NqohyGMHgUOBnwJCREoUL6sUiIFPfvKU2c72weM=; b=UA1vGmDiogVfBJZqc5RTuoRKTsJGCjXBP65SuevWfvq9zxDsxB2JHTOV 90UjB682/lsGxZ+YWZU5Dc4LMULP2XNp81ZTFI48v85yBsZfAv7sQCadU VgE4Pa7+1JHzzIrecBeCUa1ZUnsgYeQI4E5oPglCQumm03ja6F/TqHngQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAPBX5lGtJV2b/2dsb2JhbABagwY0T8I4gQ4WdIIjAQEBBAEBAWsLDAQCAQgRBAEBCx0HJwsUCAEIAgQOBQiICAy1MwSPPTEHBoMGbgOIb6A6gVmBOYIo X-IronPort-AV: E=Sophos;i="4.89,683,1367971200"; d="scan'208";a="235806496" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 17 Jul 2013 08:46:03 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6H8k2Yf027070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 08:46:02 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 03:46:02 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Avasarala, Ranjit (NSN - IN/Bangalore)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoCAAAceUIAAG3TA Date: Wed, 17 Jul 2013 08:46:02 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.222] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 08:46:13 -0000 |If many public STUN servers and call servers that implement STUN or ICElit= e=20 |functionalities, are not expected to support I should have said they have no role to play. It is similar to peer-to-peer= ICE connectivity checks -- those checks don't go through public STUN or ca= ll servers at all.=20 The difference between ICE connectivity checks and consent freshness checks= is that the former is performed before session establishment and the later= is performed after session establishment. |then who would have interest to support this functionality? RTCWEB browsers and browser-like platforms. |Ideally getting consent for receiving traffic or call should be part of si= gnaling.=20 |I do not think using STUN is appropriate. ICE already does that. You think it is inappropriate? Muthu |-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.= com] |Sent: Wednesday, July 17, 2013 12:16 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Hi Muthu | |If many public STUN servers and call servers that implement STUN or ICElit= e functionalities, are not |expected to support, then who would have interest to support this function= ality? Ideally getting |consent for receiving traffic or call should be part of signaling. I do no= t think using STUN is |appropriate. | |Regards |Ranjit | | | | |-----Original Message----- |From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |Sent: Wednesday, July 17, 2013 12:07 PM |To: Avasarala, Ranjit (NSN - IN/Bangalore) |Cc: rtcweb@ietf.org; behave@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Ranjit, | ||Many publicly available STUN servers or those that are part of Call serve= rs ||may not support this. | |Public STUN servers and call servers are not expected to support this. | ||Can't there be some other neutral mechanism to query peer's consent - thr= ough ||signaling? | |No. That signaling between the JS and the web server could be anything (SI= P or XMPP or proprietary or |whatever) and the browser has no control over it. | |Muthu | ||-----Original Message----- ||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn= .com] ||Sent: Wednesday, July 17, 2013 11:19 AM ||To: Muthu Arul Mozhi Perumal (mperumal) ||Cc: rtcweb@ietf.org; behave@ietf.org ||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||Hi Muthu || ||Though using STUN request/response may be good for querying about consent= , I feel it is overloading ||the functionality of STUN. Many publicly available STUN servers or those = that are part of Call |servers ||may not support this. || ||Can't there be some other neutral mechanism to query peer's consent - thr= ough signaling? || || ||Regards ||Ranjit || || || ||-----Original Message----- ||From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of ext Simon Perreault ||Sent: Tuesday, July 16, 2013 6:34 PM ||To: Muthu Arul Mozhi Perumal (mperumal) ||Cc: rtcweb@ietf.org; behave@ietf.org ||Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : ||> |> |> Liveness timer: If no packets have been received on the local = port in ||> |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that ||> |> |> connectivity has been lost. The JavaScript application will u= se this ||> |> |> notification however it desires (e.g., cease transmitting to t= he ||> |> |> remote peer, provide a notification to the user, etc.). ||> |> | ||> |> |This seems to me like it will not fulfill the goal set in the abstr= act: ||> |> |"to ensure that a malicious JavaScript cannot use the browser as a ||> |> |platform for launching attacks". If the JavaScript is free to ignor= e the ||> |> |notification from the browser, then it has no security benefits. If= you ||> |> |want to reach that goal, the browser needs to forcefully stop trans= mitting. ||> |> ||> |> That goal is fulfilled by the consent checks -- the browser would st= op transmitting everything |on ||> |that candidate pair, including liveness checks, if there is a consent = failure. ||> | ||> |That's not what the draft says. It says that the browser "notifies" th= e ||> |JS app. It needs to say that the browser MUST stop sending. ||> ||> No. That section is about liveness check and its intention is just noti= fy the JavaScript of a ||potential connectivity loss. It is when the consent check fails the brows= er actually stops sending ||everything. Does the draft need more text on the distinction between cons= ent and liveness tests? || ||Ah! No, you're right, and the text is already perfectly clear about ||this. No need to change. I was just confused. || ||> |> |> When not actively sending traffic on a nominated candidate pai= r, ||> |> |> performing consent freshness does not serve any purpose from a ||> |> |> security perspective. ||> |> | ||> |> |I don't understand what this means. Why is the "security perspectiv= e" ||> |> |important here? Aren't we concerned about keepalives? ||> |> ||> |> You mean one could use keepalives (Binding indications) for launchin= g attacks, so consent ||freshness ||> |would be required for sending them as well? ||> | ||> |No. ||> | ||> |This is a section about keepalives. I just don't understand this ||> |sentence, and I don't understand why it talks about security. ||> ||> Ok, let me elaborate: ||> - Consent freshness is not necessary when the browser is not sending an= y ||> traffic on a candidate pair. ||> - If the browser is not performing consent freshness on a candidate pai= r ||> for the above reason, it performs ICE keepalives (or RTP keepalives) = to ||> refresh NAT bindings. ||> ||> Of course, the browser could continue performing consent freshness even= when it is not sending any ||other traffic on that candidate pair and skip ICE keepalives. || ||Ah, ok I understand with your explanation. It makes sense. There should ||be a way to reformulate the text to make it clearer. || ||Thanks, ||Simon ||_______________________________________________ ||rtcweb mailing list ||rtcweb@ietf.org ||https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Wed Jul 17 02:02:54 2013 Return-Path: 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 D846121F9E13 for ; Wed, 17 Jul 2013 02:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 efK9mY8DqGX3 for ; Wed, 17 Jul 2013 02:02:49 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id D97A921F9DD0 for ; Wed, 17 Jul 2013 02:02:48 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so947567qcx.35 for ; Wed, 17 Jul 2013 02:02:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Ii69YmhragN4j/hHMeXfek5F74aJ9PAidKrto1vJDBc=; b=SOFBCeom60cMe2mp/k8qZtmZm4OK6zKLeCaUlz+qKwsuwPws+5kwN1n39J9HfaOdtc 3xUOTA0THVShpqTPKZktbBKI0rTDBfASq+L3IK6IR5J+Ia073zIaK/6z6FcutAVYKrGx 0gXqZAv+c3Gys/UTizzo41lhPYusKC/4pn2LV402MpS9UmKgy8qJjUhc0RfwVZt4DyaR Al0Y29CVpcOIo5a5XwTxhf5vnK61aCS+owM39S8dFxLvAeWUaawZ0MvMYVnhRwojwPmq saVjzn6ZjkiYR9glrW8LsJjxYTys3OZ4htVpbF1AEwCROwNRXYahzGuAy8ztUz8zON8n 17mA== X-Received: by 10.224.4.202 with SMTP id 10mr8144132qas.1.1374051767268; Wed, 17 Jul 2013 02:02:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 17 Jul 2013 02:02:07 -0700 (PDT) X-Originating-IP: [220.136.0.192] In-Reply-To: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> From: Eric Rescorla Date: Wed, 17 Jul 2013 17:02:07 +0800 Message-ID: To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=001a11c20dfe7dc3c104e1b15bda X-Gm-Message-State: ALoCoQlgdZ37vgQD2iFclZr05eb6y7hgotmLQcow1SPAPNjsR90P3pUkh6OUHJ6oemdtQX8NGYjR Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 09:02:55 -0000 --001a11c20dfe7dc3c104e1b15bda Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > [Added rtcweb since I am not sure if everyone involved there are followin= g > this discussion in behave] > > Thanks for the review. See inline.. > > |-----Original Message----- > |From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Simon Perreault > |Sent: Tuesday, July 16, 2013 3:05 PM > |To: behave@ietf.org > |Subject: Re: [BEHAVE] FW: I-D Action: > draft-muthu-behave-consent-freshness-04.txt > | > |Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : > |> The text and the algorithm in the draft are significantly simplified i= n > this updated version. > |> > |> Comments welcome.. > | > |MUCH better introduction. Now I feel like I understand the need exactly. > | > |The "Design Considerations" section is still very confusing to me. > | > |> Though ICE specifies STUN Binding indications to be used for > |> keepalives, it requires that an agent be prepared to receive > |> connectivity check as well. If a connectivity check is received, a > |> response is generated, but there is no impact on ICE processing, as > |> described in section 10 of [RFC5245]. > | > |...so? Why is "an impact on ICE processing" necessary? > > Meant to stress these Binding request/response doesn't trigger an ICE > restart.. > > | > |> While a WebRTC browser could verify whether the peer continues to > |> send SRTCP reports before sending traffic to the peer, the usage of > |> SRTCP together with Security Descriptions [RFC4568] requires exposi= ng > |> the media keys to the JavaScript and renders SRTCP unsuitable for > |> consent freshness. > | > |Why does it "require exposing the media keys to the JavaScript"? Is this > |because of a law of nature, or is it because of the way the JavaScript > |API is being designed? Could the JS API be changed to accommodate > |SRTCP+SDES? > > That's how the API construct looks like today -- the JavaScript would get > an SDP blob from the browser containing the crypto keys used for SDES-SRT= P. > Of course, the browser could hide those keys by putting a "****" in SDP -= :). Uh, then how would they be sent to the other side? As far as I can tell, with any plausible API SDES requires exposing the keys to JS. -Ekr --001a11c20dfe7dc3c104e1b15bda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal= ) <mperumal@cisco.com> wrote:
[Added rtcweb since I am not sure if everyon= e involved there are following this discussion in behave]

Thanks for the review. See inline..

|-----Original Message-----
|From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.o= rg] On Behalf Of Simon Perreault
|Sent: Tuesday, July 16, 2013 3:05 PM
|To: behave@ietf.org
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt
|
|Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit :
|> The text and the algorithm in the draft are signifi= cantly simplified in this updated version.
|>
|> Comments welcome..
|
|MUCH better introduction. Now I feel like I understand the need exac= tly.
|
|The "Design Considerations" section is still very confusing to m= e.
|
|> =A0 =A0Though ICE specifies STUN Binding indications to be used for |> =A0 =A0keepalives, it requires that an agent be prepared to receive |> =A0 =A0connectivity check as well. =A0If a connectivity check is rece= ived, a
|> =A0 =A0response is generated, but there is no impact on ICE processin= g, as
|> =A0 =A0described in section 10 of [RFC5245].
|
|...so? Why is "an impact on ICE processing" necessary?

Meant to stress these Binding request/response doesn't trigger an ICE r= estart..

|
|> =A0 =A0While a WebRTC browser could verify whether the peer continues= to
|> =A0 =A0send SRTCP reports before sending traffic to the peer, the usa= ge of
|> =A0 =A0SRTCP together with Security Descriptions [RFC4568] requires e= xposing
|> =A0 =A0the media keys to the JavaScript and renders SRTCP unsuitable = for
|> =A0 =A0consent freshness.
|
|Why does it "require exposing the media keys to the JavaScript"?= Is this
|because of a law of nature, or is it because of the way the JavaScript
|API is being designed? Could the JS API be changed to accommodate
|SRTCP+SDES?

That's how the API construct looks like today -- the JavaScript would g= et an SDP blob from the browser containing the crypto keys used for SDES-SR= TP. Of course, the browser could hide those keys by putting a "****&qu= ot; in SDP -:).


Uh, then how would they be sent to the o= ther side?

As far as I can tell, with any plausibl= e API SDES requires exposing the keys to JS.

-Ekr

--001a11c20dfe7dc3c104e1b15bda-- From ranjit.avasarala@nsn.com Wed Jul 17 02:07:08 2013 Return-Path: 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 9C0B821F9E39 for ; Wed, 17 Jul 2013 02:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 D1SN0mIJ5hEn for ; Wed, 17 Jul 2013 02:07:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id EE90E21F9E13 for ; Wed, 17 Jul 2013 02:07:03 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6H96tDd028834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 11:06:55 +0200 Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6H95kfu011010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 11:06:54 +0200 Received: from SGSIHTC006.nsn-intra.net (10.159.225.23) by SGSIHTC002.nsn-intra.net (10.159.225.19) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Jul 2013 17:05:55 +0800 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.242]) by SGSIHTC006.nsn-intra.net ([10.159.225.23]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 17:05:54 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: "ext Muthu Arul Mozhi Perumal (mperumal)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoCAAAceUIAAG3TAgAAKkwA= Date: Wed, 17 Jul 2013 09:05:54 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7866 X-purgate-ID: 151667::1374052015-00002EAE-4FBC3191/0-0/0-0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 09:07:08 -0000 My comments inline Regards Ranjit -----Original Message----- From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Sent: Wednesday, July 17, 2013 2:16 PM To: Avasarala, Ranjit (NSN - IN/Bangalore) Cc: rtcweb@ietf.org Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-f= reshness-04.txt |If many public STUN servers and call servers that implement STUN or ICElit= e=20 |functionalities, are not expected to support I should have said they have no role to play. It is similar to peer-to-peer= ICE connectivity checks -- those checks don't go through public STUN or ca= ll servers at all.=20 [Ranjit] But there can be scenarios where RTCWebBrowsers do talk to WebRTC = Gateways which could be co-located with call handling servers. Then it won'= t make sense to have this feature. The difference between ICE connectivity checks and consent freshness checks= is that the former is performed before session establishment and the later= is performed after session establishment. [Ranjit] Why do you need to check consent of the peer after session is esta= blished? Ideally I should check consent before session establishment. If th= e peer does not want to receive traffic, then session itself should not be = established.=20 |then who would have interest to support this functionality? RTCWEB browsers and browser-like platforms. [Ranjit] browser may implement, but it would be very customized one. I do n= ot think the intermediate entities would want to support.=20 |Ideally getting consent for receiving traffic or call should be part of si= gnaling.=20 |I do not think using STUN is appropriate. ICE already does that. You think it is inappropriate? [Ranjit] I am saying that using STUN for consent check is not appropriate a= s STUN has other dedicated functionality to do - like connectivity checks, = keep alives, etc. Also in cases of Symmetric NATs where STUN fails, TURN is= needed. Then the proposed feature would anyway fail. Muthu |-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.= com] |Sent: Wednesday, July 17, 2013 12:16 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Hi Muthu | |If many public STUN servers and call servers that implement STUN or ICElit= e functionalities, are not |expected to support, then who would have interest to support this function= ality? Ideally getting |consent for receiving traffic or call should be part of signaling. I do no= t think using STUN is |appropriate. | |Regards |Ranjit | | | | |-----Original Message----- |From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |Sent: Wednesday, July 17, 2013 12:07 PM |To: Avasarala, Ranjit (NSN - IN/Bangalore) |Cc: rtcweb@ietf.org; behave@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Ranjit, | ||Many publicly available STUN servers or those that are part of Call serve= rs ||may not support this. | |Public STUN servers and call servers are not expected to support this. | ||Can't there be some other neutral mechanism to query peer's consent - thr= ough ||signaling? | |No. That signaling between the JS and the web server could be anything (SI= P or XMPP or proprietary or |whatever) and the browser has no control over it. | |Muthu | ||-----Original Message----- ||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn= .com] ||Sent: Wednesday, July 17, 2013 11:19 AM ||To: Muthu Arul Mozhi Perumal (mperumal) ||Cc: rtcweb@ietf.org; behave@ietf.org ||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||Hi Muthu || ||Though using STUN request/response may be good for querying about consent= , I feel it is overloading ||the functionality of STUN. Many publicly available STUN servers or those = that are part of Call |servers ||may not support this. || ||Can't there be some other neutral mechanism to query peer's consent - thr= ough signaling? || || ||Regards ||Ranjit || || || ||-----Original Message----- ||From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of ext Simon Perreault ||Sent: Tuesday, July 16, 2013 6:34 PM ||To: Muthu Arul Mozhi Perumal (mperumal) ||Cc: rtcweb@ietf.org; behave@ietf.org ||Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : ||> |> |> Liveness timer: If no packets have been received on the local = port in ||> |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that ||> |> |> connectivity has been lost. The JavaScript application will u= se this ||> |> |> notification however it desires (e.g., cease transmitting to t= he ||> |> |> remote peer, provide a notification to the user, etc.). ||> |> | ||> |> |This seems to me like it will not fulfill the goal set in the abstr= act: ||> |> |"to ensure that a malicious JavaScript cannot use the browser as a ||> |> |platform for launching attacks". If the JavaScript is free to ignor= e the ||> |> |notification from the browser, then it has no security benefits. If= you ||> |> |want to reach that goal, the browser needs to forcefully stop trans= mitting. ||> |> ||> |> That goal is fulfilled by the consent checks -- the browser would st= op transmitting everything |on ||> |that candidate pair, including liveness checks, if there is a consent = failure. ||> | ||> |That's not what the draft says. It says that the browser "notifies" th= e ||> |JS app. It needs to say that the browser MUST stop sending. ||> ||> No. That section is about liveness check and its intention is just noti= fy the JavaScript of a ||potential connectivity loss. It is when the consent check fails the brows= er actually stops sending ||everything. Does the draft need more text on the distinction between cons= ent and liveness tests? || ||Ah! No, you're right, and the text is already perfectly clear about ||this. No need to change. I was just confused. || ||> |> |> When not actively sending traffic on a nominated candidate pai= r, ||> |> |> performing consent freshness does not serve any purpose from a ||> |> |> security perspective. ||> |> | ||> |> |I don't understand what this means. Why is the "security perspectiv= e" ||> |> |important here? Aren't we concerned about keepalives? ||> |> ||> |> You mean one could use keepalives (Binding indications) for launchin= g attacks, so consent ||freshness ||> |would be required for sending them as well? ||> | ||> |No. ||> | ||> |This is a section about keepalives. I just don't understand this ||> |sentence, and I don't understand why it talks about security. ||> ||> Ok, let me elaborate: ||> - Consent freshness is not necessary when the browser is not sending an= y ||> traffic on a candidate pair. ||> - If the browser is not performing consent freshness on a candidate pai= r ||> for the above reason, it performs ICE keepalives (or RTP keepalives) = to ||> refresh NAT bindings. ||> ||> Of course, the browser could continue performing consent freshness even= when it is not sending any ||other traffic on that candidate pair and skip ICE keepalives. || ||Ah, ok I understand with your explanation. It makes sense. There should ||be a way to reformulate the text to make it clearer. || ||Thanks, ||Simon ||_______________________________________________ ||rtcweb mailing list ||rtcweb@ietf.org ||https://www.ietf.org/mailman/listinfo/rtcweb From keith.drage@alcatel-lucent.com Wed Jul 17 04:07:01 2013 Return-Path: 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 C366921F9948; Wed, 17 Jul 2013 04:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 E7BkwHXD8h6U; Wed, 17 Jul 2013 04:06:56 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 41BF521F9D4A; Wed, 17 Jul 2013 04:06:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r6HB6nwZ009557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jul 2013 06:06:50 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6HB6lVR032483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 13:06:49 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 17 Jul 2013 13:06:48 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" , "dispatch@ietf.org" , "avt@ietf.org" Thread-Topic: Taxonomy Thread-Index: Ac6CNDlORSwpM9rIQtax1T6pBvHv5gAACsrAACo7ARA= Date: Wed, 17 Jul 2013 11:06:48 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [rtcweb] Taxonomy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:07:02 -0000 Breaking my own rule about cross posting... Just wanted to add is that this document would not be retrospective, i.e. w= e would not start rewriting the existing published RFCs to take into accoun= t the new terminology. The expectation however is that documents going forward from other working = groups would use the new terminology rather than other terms.=20 Obviously how this is handled is up to the individual working groups, but u= sing the new terminology will be the only good way of making your results u= nderstandable outside your specific field. So that is why your review and input is important. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 16 July 2013 15:58 > To: mmusic@ietf.org; rtcweb@ietf.org; clue@ietf.org; dispatch@ietf.org; > avt@ietf.org > Subject: FW: Taxonomy >=20 > Extensive cross-post do not reply to this email. >=20 > For information. We do expect participation input from all the listed > working groups (and possibly more). >=20 > Keith >=20 > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of DRAGE, Keith (Keith) > Sent: 16 July 2013 15:53 > To: avtext@ietf.org > Subject: [avtext] Taxonomy >=20 > (As AVTEXT WG cochair) >=20 > The latest version of the RTP taxonomy draft has been submitted. >=20 > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping- > taxonomy/ >=20 > This document was allocated to AVTEXT by DISPATCH, and we have created a > milestone for it in AVTEXT. >=20 > This draft is not yet a working group document. >=20 > We do expect to spend some significant meeting time discussing the > contents in the AVTEXT meeting in Berlin, so please start raising your > issues on the AVTEXT list. >=20 > Additionally, if there are counter proposals existing that the AVTEXT > chairs would not otherwise be aware of, then please identify them to the > AVTEXT chairs / list. >=20 > Regards >=20 > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From ibc@aliax.net Wed Jul 17 04:27:12 2013 Return-Path: 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 D910321F9D92 for ; Wed, 17 Jul 2013 04:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 b3hV8HvwRWtw for ; Wed, 17 Jul 2013 04:27:12 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9278421F9DAF for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so1029819qab.4 for ; Wed, 17 Jul 2013 04:27:08 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=EKaU4MI2ZQsAWPvMCk3JxHj6BeoOuRCIjkCYNQ+jx9I=; b=NHnHv377v8o772OwwsztN82Dj4IVI7F1dpxq2tr7tzmEZqHeBKumqS99+50m7VHL0E VrWA7DjGO9gsdYqbTcs15O6SWe/bARlDtZpJJg6q7cRbT++dzAHAc897qiZ40VKex/4E onXtMvGHcOwAuEAbCWdfw1XaTeSjtsQxeoemyFBv8ZFotSXoZ7pLgmlE4aiza7wFyTBr +efKCodu2U+kSSec5APFfPx29CXJ0nO/l221+bDE0fuh25F24iM/9wHi94nComde8HHJ nktVAXoN+S2cQ+QkntFrt1rkIeO8WqIJCbNVYu+RZ6xkgZWaWm/1SR83SRMc74nRqzEm B9Zg== X-Received: by 10.224.90.1 with SMTP id g1mr8708293qam.0.1374060427977; Wed, 17 Jul 2013 04:27:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 17 Jul 2013 04:26:47 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B06B7FA@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 17 Jul 2013 13:26:47 +0200 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmUxz9ZCXFbwm6NFlOJ0Ye8+LakmtvEyBgIcUnQY1NCoL9XVGHSfSsE4Yo5dsmRIRKvVZKE Cc: "clue@ietf.org" , "dispatch@ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" , "avt@ietf.org" Subject: Re: [rtcweb] [dispatch] Taxonomy X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:27:13 -0000 2013/7/17 DRAGE, Keith (Keith) : > The expectation however is that documents going forward from other workin= g groups would use the new terminology rather than other terms. > > Obviously how this is handled is up to the individual working groups, but= using the new terminology will be the only good way of making your results= understandable outside your specific field. > > So that is why your review and input is important. Hi Drage, First of I'm sorry but I'm not subscribed to MMUSIC nor CLUE, so let me please reply here (it is just a single topic): I'm really annoying after reading the draft section 2.4 "Media Stream": http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01#= section-2.4 ------------------------ Each Media Stream is identified by a unique Synchronization source (SSRC) [RFC3550] that is carried in every RTP and Real-time Transport Control Protocol (RTCP) packet header. ------------------------ In W3C we have "MediaStream" and "MediaStreamTrack", and "MediaStreamTrack" is exactly what the draft above defines as "Media Stream". So let me say that this is the most confusing terminology it can be. -- I=C3=B1aki Baz Castillo From simon.perreault@viagenie.ca Wed Jul 17 04:51:53 2013 Return-Path: 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 9773F21F9D92 for ; Wed, 17 Jul 2013 04:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, 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 Df9U5rsT1vt2 for ; Wed, 17 Jul 2013 04:51:53 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C72E21F9C70 for ; Wed, 17 Jul 2013 04:51:53 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:5b8:1f9e:c21b:48d7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8E42B403EE for ; Wed, 17 Jul 2013 07:51:52 -0400 (EDT) Message-ID: <51E68556.30708@viagenie.ca> Date: Wed, 17 Jul 2013 13:51:50 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:51:53 -0000 Le 2013-07-17 11:05, Avasarala, Ranjit (NSN - IN/Bangalore) a écrit : > Why do you need to check consent of the peer after session is established? [...] > I am saying that using STUN for consent check is not appropriate [...] Ranjit, I would expect one to fully understand the need for consent checks *before* declaring the proposed solution inappropriate. Simon From mperumal@cisco.com Wed Jul 17 05:47:11 2013 Return-Path: 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 9056521F9F1F; Wed, 17 Jul 2013 05:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 dpwx76Zv98hK; Wed, 17 Jul 2013 05:47:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 100C121F93F3; Wed, 17 Jul 2013 05:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10713; q=dns/txt; s=iport; t=1374065224; x=1375274824; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=acefHav8uesKiFqyNunNL1n1Q7yunoMBUteqB8MR/3Q=; b=gGLLWJbHrMKl6YuA509eqwLvslbAzPuXas3EcX0PcKZ02UoxIt/b97Co vHG2uKxELYd6avK8D0u2FwY5tIb6o/PqMbO9VXAX9XHYyWcFa0m+tXTUf /lP5XuR9tgcrTe8nWqqZ6Xgh4fqBA98ieP1zLXJKcShWTMlYJ7tjFBtV4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAAqR5lGtJXHA/2dsb2JhbABagkJEgQPCUoEPFnSCIwEBAQQtTAwEAgEIDgMEAQELHQcyFAgBCAIEDgUIiAi1do89MQYBBoMGbgOIb6A6gVmBOYIo X-IronPort-AV: E=Sophos;i="4.89,684,1367971200"; d="scan'208,217";a="235907664" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jul 2013 12:47:03 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HCl334027265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 12:47:03 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 07:47:02 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Eric Rescorla Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOguu8ib6iXKrxjkSuS/iDhawvUw== Date: Wed, 17 Jul 2013 12:47:02 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.164] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE22419C35Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 12:47:11 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE22419C35Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable |Uh, then how would they be sent to the other side? Ah, the browser would have to modify the SDP when it is sent on the wire.. |As far as I can tell, with any plausible API SDES requires exposing the ke= ys to JS. That helps..thanks. Muthu From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Wednesday, July 17, 2013 2:32 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Simon Perreault; behave@ietf.org; rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-f= reshness-04.txt On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal) > wrote: [Added rtcweb since I am not sure if everyone involved there are following = this discussion in behave] Thanks for the review. See inline.. |-----Original Message----- |From: behave-bounces@ietf.org [mailto:beha= ve-bounces@ietf.org] On Behalf Of Simon Per= reault |Sent: Tuesday, July 16, 2013 3:05 PM |To: behave@ietf.org |Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt | |Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |> The text and the algorithm in the draft are significantly simplified in = this updated version. |> |> Comments welcome.. | |MUCH better introduction. Now I feel like I understand the need exactly. | |The "Design Considerations" section is still very confusing to me. | |> Though ICE specifies STUN Binding indications to be used for |> keepalives, it requires that an agent be prepared to receive |> connectivity check as well. If a connectivity check is received, a |> response is generated, but there is no impact on ICE processing, as |> described in section 10 of [RFC5245]. | |...so? Why is "an impact on ICE processing" necessary? Meant to stress these Binding request/response doesn't trigger an ICE resta= rt.. | |> While a WebRTC browser could verify whether the peer continues to |> send SRTCP reports before sending traffic to the peer, the usage of |> SRTCP together with Security Descriptions [RFC4568] requires exposing |> the media keys to the JavaScript and renders SRTCP unsuitable for |> consent freshness. | |Why does it "require exposing the media keys to the JavaScript"? Is this |because of a law of nature, or is it because of the way the JavaScript |API is being designed? Could the JS API be changed to accommodate |SRTCP+SDES? That's how the API construct looks like today -- the JavaScript would get a= n SDP blob from the browser containing the crypto keys used for SDES-SRTP. = Of course, the browser could hide those keys by putting a "****" in SDP -:)= . Uh, then how would they be sent to the other side? As far as I can tell, with any plausible API SDES requires exposing the key= s to JS. -Ekr --_000_E721D8C6A2E1544DB2DEBC313AF54DE22419C35Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

|Uh, then how would they be sent to the other side?

 

Ah, the browser would have to modify the SDP when it is se= nt on the wire..

 

|As far as I can tell, with any plausible API SDES require= s exposing the keys to JS.

 

That helps..thanks.

 

Muthu

 

From: Eric Res= corla [mailto:ekr@rtfm.com]
Sent: Wednesday, July 17, 2013 2:32 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Simon Perreault; behave@ietf.org; rtcweb@ietf.org
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-co= nsent-freshness-04.txt

 

 

 

On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Pe= rumal (mperumal) <mperumal@cisco.com> wrote:

[Added rtcweb since I am not sure if everyone involv= ed there are following this discussion in behave]

Thanks for the review. See inline..

|-----Original Message-----
|From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.o= rg] On Behalf Of Simon Perreault
|Sent: Tuesday, July 16, 2013 3:05 PM
|To: behave@ietf.org
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt
|
|Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit :<= /o:p>

|> The text and the algorithm in the draft are si= gnificantly simplified in this updated version.
|>
|> Comments welcome..
|

|MUCH better introduction. Now I feel like I underst= and the need exactly.
|
|The "Design Considerations" section is still very confusing to m= e.
|
|>    Though ICE specifies STUN Binding indications to be used= for
|>    keepalives, it requires that an agent be prepared to rec= eive
|>    connectivity check as well.  If a connectivity chec= k is received, a
|>    response is generated, but there is no impact on ICE pro= cessing, as
|>    described in section 10 of [RFC5245].
|
|...so? Why is "an impact on ICE processing" necessary?

Meant to stress these Binding request/response doesn't trigger an ICE resta= rt..

|
|>    While a WebRTC browser could verify whether the peer con= tinues to
|>    send SRTCP reports before sending traffic to the peer, t= he usage of
|>    SRTCP together with Security Descriptions [RFC4568] requ= ires exposing
|>    the media keys to the JavaScript and renders SRTCP unsui= table for
|>    consent freshness.
|
|Why does it "require exposing the media keys to the JavaScript"?= Is this
|because of a law of nature, or is it because of the way the JavaScript
|API is being designed? Could the JS API be changed to accommodate
|SRTCP+SDES?

That's how the API construct looks like today -- the JavaScript would get a= n SDP blob from the browser containing the crypto keys used for SDES-SRTP. = Of course, the browser could hide those keys by putting a "****" = in SDP -:).

 

 

Uh, then how would they be sent to the other side?

 

As far as I can tell, with any plausible API SDES re= quires exposing the keys to JS.

 

-Ekr

 

--_000_E721D8C6A2E1544DB2DEBC313AF54DE22419C35Dxmbrcdx02ciscoc_-- From mperumal@cisco.com Wed Jul 17 07:18:00 2013 Return-Path: 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 AF91F21F94DC for ; Wed, 17 Jul 2013 07:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EIi123cToOBr for ; Wed, 17 Jul 2013 07:17:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5D90521F91F4 for ; Wed, 17 Jul 2013 07:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9852; q=dns/txt; s=iport; t=1374070675; x=1375280275; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C/dq49jMVhV2PDCtc3w0UuKH/jgUtC3b2vcBbZFwWaM=; b=NcLPaP5vRtPcHn3/6IvwpA3HjJA+HebLsrau5aLq73ElD02LaWQP3JRM 8xt4ZHk/jYSO+P1N4w+EprzBz7Jep7PY2aTcg9SXH7jLVnARHoVlFXHxw 5OTeQRbqCQ6Rp0rfrJ7Pxbdef7hFAW/1N8LohLNStNktrVirskcrgoQVX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAAym5lGtJV2a/2dsb2JhbABagwY0UMJRgRAWdIIjAQEBBAEBAWsLDAQCAQgRBAEBCx0HJwsUCAEIAgQOBQgTh3UMtg0Ej0kGKwcGgwduA4hvoDqBWYE5gWgFAjk X-IronPort-AV: E=Sophos;i="4.89,685,1367971200"; d="scan'208";a="235960501" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jul 2013 14:17:54 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6HEHsqW017923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 14:17:54 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 09:17:54 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Avasarala, Ranjit (NSN - IN/Bangalore)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoCAAAceUIAAG3TAgAAKkwCAAFNjgA== Date: Wed, 17 Jul 2013 14:17:53 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.164] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 14:18:00 -0000 |-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.= com] |Sent: Wednesday, July 17, 2013 2:36 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |My comments inline | |Regards |Ranjit | |-----Original Message----- |From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |Sent: Wednesday, July 17, 2013 2:16 PM |To: Avasarala, Ranjit (NSN - IN/Bangalore) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | ||If many public STUN servers and call servers that implement STUN or ICEli= te ||functionalities, are not expected to support | |I should have said they have no role to play. It is similar to peer-to-pee= r ICE connectivity checks -- |those checks don't go through public STUN or call servers at all. |[Ranjit] But there can be scenarios where RTCWebBrowsers do talk to WebRTC= Gateways which could be co- |located with call handling servers. Then it won't make sense to have this = feature. An RTCWeb gateway wouldn't have to do anything fancier than what it already= does for ICE connectivity checks.=20 | |The difference between ICE connectivity checks and consent freshness check= s is that the former is |performed before session establishment and the later is performed after se= ssion establishment. |[Ranjit] Why do you need to check consent of the peer after session is est= ablished? Ideally I should |check consent before session establishment. If the peer does not want to r= eceive traffic, then session |itself should not be established. See draft-ietf-rtcweb-security-arch: 4.4. Communications and Consent Freshness From a security perspective, everything from here on in is a little anticlimactic: Alice and Bob exchange data protected by the keys negotiated by DTLS. Because of the security guarantees discussed in the previous sections, they know that the communications are encrypted and authenticated. The one remaining security property we need to establish is "consent freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline. ICE specifies periodic STUN keepalizes but only if media is not flowing. Because the consent issue is more difficult here, we require RTCWeb implementations to periodically send keepalives. As described in Section 5.3, these keepalives MUST be based on the consent freshness mechanism specified in [I-D.muthu-behave-consent-freshness]. If a keepalive fails and no new ICE channels can be established, then the session is terminated. | ||then who would have interest to support this functionality? | |RTCWEB browsers and browser-like platforms. |[Ranjit] browser may implement, but it would be very customized one. I do = not think the intermediate |entities would want to support. You seem to be completely missing the very purpose of consent. | ||Ideally getting consent for receiving traffic or call should be part of s= ignaling. ||I do not think using STUN is appropriate. | |ICE already does that. You think it is inappropriate? |[Ranjit] I am saying that using STUN for consent check is not appropriate = as STUN has other dedicated |functionality to do - like connectivity checks, keep alives, etc.=20 See draft-ietf-rtcweb-security and draft-ietf-rtcweb-security. |Also in cases of Symmetric NATs where STUN fails, TURN is needed. Then the= proposed feature would anyway fail. The solution is built on top of ICE, so should work across these. Muthu | |Muthu | ||-----Original Message----- ||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn= .com] ||Sent: Wednesday, July 17, 2013 12:16 PM ||To: Muthu Arul Mozhi Perumal (mperumal) ||Cc: rtcweb@ietf.org ||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||Hi Muthu || ||If many public STUN servers and call servers that implement STUN or ICEli= te functionalities, are not ||expected to support, then who would have interest to support this functio= nality? Ideally getting ||consent for receiving traffic or call should be part of signaling. I do n= ot think using STUN is ||appropriate. || ||Regards ||Ranjit || || || || ||-----Original Message----- ||From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] ||Sent: Wednesday, July 17, 2013 12:07 PM ||To: Avasarala, Ranjit (NSN - IN/Bangalore) ||Cc: rtcweb@ietf.org; behave@ietf.org ||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||Ranjit, || |||Many publicly available STUN servers or those that are part of Call serv= ers |||may not support this. || ||Public STUN servers and call servers are not expected to support this. || |||Can't there be some other neutral mechanism to query peer's consent - th= rough |||signaling? || ||No. That signaling between the JS and the web server could be anything (S= IP or XMPP or proprietary or ||whatever) and the browser has no control over it. || ||Muthu || |||-----Original Message----- |||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@ns= n.com] |||Sent: Wednesday, July 17, 2013 11:19 AM |||To: Muthu Arul Mozhi Perumal (mperumal) |||Cc: rtcweb@ietf.org; behave@ietf.org |||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consen= t-freshness-04.txt ||| |||Hi Muthu ||| |||Though using STUN request/response may be good for querying about consen= t, I feel it is overloading |||the functionality of STUN. Many publicly available STUN servers or those= that are part of Call ||servers |||may not support this. ||| |||Can't there be some other neutral mechanism to query peer's consent - th= rough signaling? ||| ||| |||Regards |||Ranjit ||| ||| ||| |||-----Original Message----- |||From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf= Of ext Simon Perreault |||Sent: Tuesday, July 16, 2013 6:34 PM |||To: Muthu Arul Mozhi Perumal (mperumal) |||Cc: rtcweb@ietf.org; behave@ietf.org |||Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consen= t-freshness-04.txt ||| |||Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |||> |> |> Liveness timer: If no packets have been received on the local= port in |||> |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript tha= t |||> |> |> connectivity has been lost. The JavaScript application will = use this |||> |> |> notification however it desires (e.g., cease transmitting to = the |||> |> |> remote peer, provide a notification to the user, etc.). |||> |> | |||> |> |This seems to me like it will not fulfill the goal set in the abst= ract: |||> |> |"to ensure that a malicious JavaScript cannot use the browser as a |||> |> |platform for launching attacks". If the JavaScript is free to igno= re the |||> |> |notification from the browser, then it has no security benefits. I= f you |||> |> |want to reach that goal, the browser needs to forcefully stop tran= smitting. |||> |> |||> |> That goal is fulfilled by the consent checks -- the browser would s= top transmitting everything ||on |||> |that candidate pair, including liveness checks, if there is a consent= failure. |||> | |||> |That's not what the draft says. It says that the browser "notifies" t= he |||> |JS app. It needs to say that the browser MUST stop sending. |||> |||> No. That section is about liveness check and its intention is just not= ify the JavaScript of a |||potential connectivity loss. It is when the consent check fails the brow= ser actually stops sending |||everything. Does the draft need more text on the distinction between con= sent and liveness tests? ||| |||Ah! No, you're right, and the text is already perfectly clear about |||this. No need to change. I was just confused. ||| |||> |> |> When not actively sending traffic on a nominated candidate pa= ir, |||> |> |> performing consent freshness does not serve any purpose from = a |||> |> |> security perspective. |||> |> | |||> |> |I don't understand what this means. Why is the "security perspecti= ve" |||> |> |important here? Aren't we concerned about keepalives? |||> |> |||> |> You mean one could use keepalives (Binding indications) for launchi= ng attacks, so consent |||freshness |||> |would be required for sending them as well? |||> | |||> |No. |||> | |||> |This is a section about keepalives. I just don't understand this |||> |sentence, and I don't understand why it talks about security. |||> |||> Ok, let me elaborate: |||> - Consent freshness is not necessary when the browser is not sending a= ny |||> traffic on a candidate pair. |||> - If the browser is not performing consent freshness on a candidate pa= ir |||> for the above reason, it performs ICE keepalives (or RTP keepalives)= to |||> refresh NAT bindings. |||> |||> Of course, the browser could continue performing consent freshness eve= n when it is not sending any |||other traffic on that candidate pair and skip ICE keepalives. ||| |||Ah, ok I understand with your explanation. It makes sense. There should |||be a way to reformulate the text to make it clearer. ||| |||Thanks, |||Simon |||_______________________________________________ |||rtcweb mailing list |||rtcweb@ietf.org |||https://www.ietf.org/mailman/listinfo/rtcweb From rajmohanbanavi@gmail.com Wed Jul 17 11:56:24 2013 Return-Path: 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 421D921E804D; Wed, 17 Jul 2013 11:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 abFslb4-zksj; Wed, 17 Jul 2013 11:56:23 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2408C21F9F3A; Wed, 17 Jul 2013 11:56:23 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id u16so4851653iet.23 for ; Wed, 17 Jul 2013 11:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kT2Gvojh7D6+x9vC06KDxYq/tyr+eD3rI7eNZ/5V4QI=; b=bztslltZO4fwWEH+i5uADB2fpu1DJ8QppKHJl0b5Y3YmFGGHVTf8CwEhVKtk458T+V 3ORRrqOjNZkU5TdMl5ICQEuMtetVCOj3gxBDWUhv3FbU4QqoY9bkdlGogFHK2j0jsstV 2R39Sd+JAErusJarWqdMt55ViuYu62pper4j3DVMflBpkQPKCCrhsKD/OPXwuHsm0zMv v1ds7EHYyx5/4AQEpxeK5CfX9gUjoquOrfXi2sspsDMATAVwLj9BNnoUYOPHEj//twz/ wsZAEVi/bICf3IUlKpRKcFSBGtgaZmgjadj8fWocxS4oI3L+m2cxFGE1JNSSjUxDqL19 RELg== MIME-Version: 1.0 X-Received: by 10.50.66.210 with SMTP id h18mr11086023igt.19.1374087382679; Wed, 17 Jul 2013 11:56:22 -0700 (PDT) Received: by 10.42.152.9 with HTTP; Wed, 17 Jul 2013 11:56:22 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2013 00:26:22 +0530 Message-ID: From: Rajmohan Banavi To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bdca46855c97504e1b9a6dd Cc: behave@ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:56:24 -0000 --047d7bdca46855c97504e1b9a6dd Content-Type: text/plain; charset=ISO-8859-1 Hi Justin, I reviewed draft-uberti-behave-turn-rest-00 and have the following comments. 1. IMHO, calling the API as REST does not seem to be appropriate since the API does not follow the REST principles of addressing/operating on a resource. 2. Sec 4.3 last paragraph - "Because the password is derived from the USERNAME, successful verification of the MESSAGE-INTEGRITY ensures that the username is trustworthy". I believe this validation is taken care of in the TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN client generates a long term key which is computed as => key = MD5(username ":" realm ":" SASLprep(password)). This key is used to perform hmac on the message. The same is done on the TURN server end as well. If the MESSAGE-INTEGRITY is verified, then it implies that the username is trustworthy. So why not just generate a TURN password randomly? This would avoid the need to have a secret key between the TURN server and the webrtc app. Am I missing any scenario here where this extra security is required? 3. sec 4.1 Client - Does it make it more clear if we reword the last sentence as - and the "password" value as input to generate the HMAC digest key used while calculating MESSAGE-INTEGRITY hash. 4. Sec 5.1 Revocation - Why is revoking of specific credentials not possible? Probably need more clarity on who would try to revoke the credentials and under what scenario? 5. Sec 5.2 Key Rotation - I presume here that the shared secret mentioned is the one shared between the TURN server and the webrtc application. The TURN password once generated using say secretkey1 and user1 will be valid on the TURN server till the expiry timeout (as per suggested value of 1 day) value. Why do we then need the TURN server to validate the message integrity against 2 secret keys? Wouldn't this behavior not contradict the one stated in TURN RFC? Thanks, Rajmohan MindBricks On Tue, Jul 16, 2013 at 3:22 AM, Justin Uberti wrote: > I have changed the WG for this draft from RTCWEB to BEHAVE. Many, but not > all of the comments I received on the RTCWEB mailing list have been > addressed. > > BEHAVE chairs, I would like 10 minutes of agenda time to discuss this > draft. > > ---------- Forwarded message ---------- > From: > Date: Mon, Jul 15, 2013 at 5:49 PM > Subject: New Version Notification for draft-uberti-behave-turn-rest-00.txt > To: Justin Uberti > > > > A new version of I-D, draft-uberti-behave-turn-rest-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-behave-turn-rest > Revision: 00 > Title: A REST API For Access To TURN Services > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt > Status: > http://datatracker.ietf.org/doc/draft-uberti-behave-turn-rest > Htmlized: > http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 > > > Abstract: > This document describes a proposed standard REST API for obtaining > access to TURN services via ephemeral (i.e. time-limited) > credentials. These credentials are vended by a web service over > HTTP, and then supplied to and checked by a TURN server using the > standard TURN protocol. The usage of ephemeral credentials ensures > that access to the TURN server can be controlled even if the > credentials can be discovered by the user, as is the case in WebRTC > where TURN credentials must be specified in Javascript. > > > > > The IETF Secretariat > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Life is here and now, not yesterday, not tomorrow...! --047d7bdca46855c97504e1b9a6dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Justin,

I reviewed=A0draft-uberti-behave-turn-rest-<= span style=3D"font-family:arial,sans-serif;font-size:13px">00=A0and have the following comments.
  1. IMHO, calling the API as REST does not seem to be appropriate since= the API does not follow the REST principles of addressing/operating on a r= esource.
  2. Sec 4.3 last paragraph - "Because the password is der= ived from the USERNAME, successful verification of the MESSAGE-INTEGRITY en= sures that the username is trustworthy". I believe this validation is = taken care of in the TURN RFC itself. In order to generate the MESSAGE-INTE= GRITY, the TURN client generates a long term key which is computed as =3D&g= t;=A0key =3D MD5(username &q= uot;:" realm ":" SASLprep(password)). This key is used to pe= rform hmac on the message. The same is done on the TURN server end as well.= If the MESSAGE-INTEGRITY is verified, then it implies that the username is= trustworthy. So=A0why not just generate a TURN password randomly? T= his would avoid the need to have a secret key between the TURN server and t= he webrtc app. Am I missing any scenario here where this extra security is = required?
  3. sec 4.1 Client - Does it make it more clear if we reword the last sente= nce as - and the "password" value as input to generate the HMAC d= igest key used while calculating MESSAGE-INTEGRITY hash.
  4. Sec 5.1 Re= vocation - Why is revoking of specific credentials not possible? Probably n= eed more clarity on who would try to revoke the credentials and under what = scenario?
  5. Sec 5.2 Key Rotation - I presume here that the shared secret mentioned = is the one shared between the TURN server and the webrtc application. The T= URN password once generated using say secretkey1 and user1 will be valid on= the TURN server till the expiry timeout (as per suggested value of 1 day) = value. Why do we then need the TURN server to validate the message integrit= y against 2 secret keys? Wouldn't this behavior not contradict the one = stated in TURN RFC?
Thanks,
Rajmohan
MindBricks


On Tue, Jul 16, 2013= at 3:22 AM, Justin Uberti <juberti@google.com> wrote:
I have changed the WG for t= his draft from RTCWEB to BEHAVE. Many, but not all of the comments I receiv= ed on the RTCWEB mailing list have been addressed.

BEHAVE chairs, I would like= 10 minutes of agenda time to discuss this draft.

---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
Date: Mon, Jul 15, 2013 at 5:49 PM
Subject: New Version Notification for= draft-uberti-behave-turn-rest-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-behave-turn-rest-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-uberti-behave-turn-rest
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 A REST API For Access To TURN Services
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.or= g/internet-drafts/draft-uberti-behave-turn-rest-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc= /draft-uberti-behave-turn-rest
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ub= erti-behave-turn-rest-00


Abstract:
=A0 =A0This document describes a proposed standard REST API for obtaining =A0 =A0access to TURN services via ephemeral (i.e. time-limited)
=A0 =A0credentials. =A0These credentials are vended by a web service over =A0 =A0HTTP, and then supplied to and checked by a TURN server using the =A0 =A0standard TURN protocol. =A0The usage of ephemeral credentials ensure= s
=A0 =A0that access to the TURN server can be controlled even if the
=A0 =A0credentials can be discovered by the user, as is the case in WebRTC<= br> =A0 =A0where TURN credentials must be specified in Javascript.




The IETF Secretariat




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




--

Life= is here and now, not yesterday, not tomorrow...!
--047d7bdca46855c97504e1b9a6dd-- From fippo@goodadvice.pages.de Wed Jul 17 13:40:09 2013 Return-Path: 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 19D6D21F9DFA; Wed, 17 Jul 2013 13:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 1ZpfXPyWas-2; Wed, 17 Jul 2013 13:39:50 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4FA21F9344; Wed, 17 Jul 2013 13:39:49 -0700 (PDT) Received: from [192.168.2.100] (p549700D7.dip0.t-ipconnect.de [84.151.0.215]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6HKddb9026363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 22:39:44 +0200 Message-ID: <51E70106.8060100@goodadvice.pages.de> Date: Wed, 17 Jul 2013 22:39:34 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: rajmohanbanavi@gmail.com References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:40:09 -0000 Am 17.07.2013 20:56, schrieb Rajmohan Banavi: > Hi Justin, > > I reviewed draft-uberti-behave-turn-rest-00 and have the following comments. [...] > 2. Sec 4.3 last paragraph - "Because the password is derived from the > USERNAME, successful verification of the MESSAGE-INTEGRITY ensures that the > username is trustworthy". I believe this validation is taken care of in the > TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN > client generates a long term key which is computed as => key = > MD5(username ":" realm ":" SASLprep(password)). This key is used to perform > hmac on the message. The same is done on the TURN server end as well. If > the MESSAGE-INTEGRITY is verified, then it implies that the username is > trustworthy. Let me try to address that with a lenghty example: The web server returns password = BASE64(HMAC-SHA1(username, sharedsecret)) to the browser. For example, with username = "12334939:mbzrxpgjys" and sharedsecret "secret", the password given to the browser would be "+4pCXR06gx/cqAikLYnBajtZW6E=" (hopefully) The browser passes the username, uri and password to it's webrtc stack. The password is exposed to the user of the browser (which might be anyone surfing your website) during that process. That stack does long term authentication and uses this password string as input for calculating MESSAGE-INTEGRITY with key = MD5(username ":" realm ":" SASLprep(password)) For the example this would be key =MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=") On the TURN server, the key for MESSAGE-INTEGRITY is calculated using key = MD5(username ":" realm ":" SASLprep(BASE64(HMAC-SHA1(USERNAME, sharedsecret)) So for the example this would be = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep(BASE64(HMAC-SHA1("12334939:mbzrxpgjys", "secret")) = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=") So the browser and turn server use the same input to the M-I. This can be done by looking at the request alone given the shared secret. Does that make it clearer? philipp, who only understood it after implementing it From matthew.kaufman@skype.net Wed Jul 17 13:49:17 2013 Return-Path: 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 48E3621F9FBD for ; Wed, 17 Jul 2013 13:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[AWL=-0.423, 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 OG2hkCeq0W62 for ; Wed, 17 Jul 2013 13:49:10 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 4887521F9D30 for ; Wed, 17 Jul 2013 13:49:10 -0700 (PDT) Received: from mail195-db8-R.bigfish.com (10.174.8.247) by DB8EHSOBE031.bigfish.com (10.174.4.94) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 20:49:09 +0000 Received: from mail195-db8 (localhost [127.0.0.1]) by mail195-db8-R.bigfish.com (Postfix) with ESMTP id EBFFC340279; Wed, 17 Jul 2013 20:49:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail195-db8: 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=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail195-db8 (localhost.localdomain [127.0.0.1]) by mail195-db8 (MessageSwitch) id 13740941462949_6372; Wed, 17 Jul 2013 20:49:06 +0000 (UTC) Received: from DB8EHSMHS011.bigfish.com (unknown [10.174.8.225]) by mail195-db8.bigfish.com (Postfix) with ESMTP id E9FB7A00049; Wed, 17 Jul 2013 20:49:05 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB8EHSMHS011.bigfish.com (10.174.4.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 17 Jul 2013 20:49:05 +0000 Received: from TK5EX14MBXC265.redmond.corp.microsoft.com ([169.254.3.88]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0136.001; Wed, 17 Jul 2013 20:48:56 +0000 From: "Matthew Kaufman (SKYPE)" To: Hadriel Kaplan , "rtcweb@ietf.org" Thread-Topic: [rtcweb] A compromise for SDES Thread-Index: AQHOf/PzdBY2ORj9Kk6EkBvQKQCpV5lpW/iw Date: Wed, 17 Jul 2013 20:48:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] 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% Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:49:17 -0000 Hadriel Kaplan: > > Howdy, > Someone's asked me to explain the compromise I plan on presenting in > Berlin now, so we have more time to argue over it or chew on it. The rea= son > I was going to wait is because I wanted to explain how I got to the point= of > thinking such a compromise would make sense. So I'll try to do that in t= his > email, which will make this email long. Nothin' much I can do about that= . >=20 > Obviously this is all my personal opinion, not that of my employer, and n= ot a > statement claiming to be objective fact, etc. Likewise, in this reply where, though I like you, I don't like your proposa= l. >=20 > Background: > I think many people would agree that SDES has some benefits compared to > DTLS for those of us wishing to interface to the SIP world. Some of thos= e > benefits are commercial/cost factors, some are more tangible like reducin= g > early media clipping. Whether you agree with such benefits or not, so lo= ng as > WebRTC could support SDES in a sufficiently-secure manner, there'd be les= s > concern over having it. Most of the arguments against SDES have been > directed at whether it could in fact be "sufficiently secure". Personall= y I find > most of the arguments against it being secure enough to be essentially FU= D, > and/or also apply to DTLS-SRTP. I believe that once the entire system is considered, any system that allows= EKT shares the same security properties as one that allows SDES, and one t= hat does not allow EKT requires a decrypt/re-encrypt phase at the gateway t= hat is costly. >=20 > On the flip-side, I think the commercial/cost factor for SDES is not a st= rong > cause, because I believe the market will bear whatever the extra cost may > be. (I wasn't sure of this 2 years ago when this all started, but I'm fai= rly > confident of it now) And I think having only DTLS-SRTP as MTI would have= a > marketing benefit for WebRTC as a technology, which I value highly. The market might bear the extra cost, but it doesn't mean that it isn't ext= ra cost (and extra environmental damage through the extra energy consumed). >=20 > Given those personal feelings, I didn't much care either way, so long as = a > decision was made - although I still preferred having SDES to avoid the e= arly > media clipping problem. So when I was going to present on this topic bac= k in > the Vancouver meeting, my last slide basically said: "If we support SDES = and it > turns out later we were wrong, we can always rescind it". This was based= on > the notion that browsers get updated all the time, especially for securit= y > issues. >=20 > But later it occurred to me that's actually the Achilles' heel of support= ing SDES > in WebRTC, for those of us wanting to gateway this stuff to SIP. Imagine= if it > turns out we were wrong, and some expected-or-unexpected vulnerability is > exploited against some large WebRTC service provider, and makes the > news/slashdot. Browser vendors would instantly have new code removing > SDES support, and browsers in devices would be updated virtually overnigh= t - > some users may take a long time to upgrade their specific browsers on the= ir > specific devices - but many of them would do so within days. That would = be > untenable for a WebRTC service provider.=20 I can't imagine such a scenario that couldn't also happen with DTLS-SRTP, e= specially DTLS-SRTP + EKT. Plus there's lots of counterexamples where major sites have been compromise= d in ways that could have been fixed browser-side, and yet browsers didn't = bother to update. And finally, what makes you think that the browser vendors would do somethi= ng like that if the service really was popular? I guess if Google and Mozil= la wanted everyone using Skype to switch to Internet Explorer they could pu= ll such a stunt, but why? (In a hypothetical future where IE has webrtc sup= port and Skype supports webrtc-equipped browsers as a platform for calling,= of course) > Even the smaller Enterprises take > a long time to upgrade code on their servers, so even for them changing t= heir > gateways to suddenly support DTLS-SRTP would be unrealistic. Imagine wha= t > it would be for larger providers, who might even have to deploy more > servers to handle the sudden additional overhead of DTLS-SRTP. Meanwhile > a growing perc entage of their users can no longer use the service. Tha= t's > bad mojo. I argue that it'd never happen. >=20 > The things that a WebRTC-to-SIP service provider can control, and arguabl= y > the much larger use-case for this stuff to begin with, are not really tru= e > "browsers" anyway - they're web-based-framework device Apps, provided > by the service provider to begin with. I.e., the apps they build using w= eb > application framework things like PhoneGap/Cordova, Appcelerator > Titanium, etc. I mean using a real Browser is nice for ad-hoc stuff, lik= e being > able to click on a "talk to a rep" button on a website, or a webex/meetec= ho > type thing; but for real communication "service", whether it be as a > subscriber of a traditional carrier, or Skype, or an employee of an Enter= prise, > or a call-center attendant, or whatever - for those most people would nev= er > want to have to open a browser just to receive/make calls. They'd give y= ou > an app to use instead. >=20 > So it's the app use-case that would benefit the most from SDES, especiall= y for > issues like media clipping. And the app use-case doesn't have the securi= ty > concerns nor concerns for unforeseen overnight updates. And will probably support SDES. >=20 > The Compromise: > So given that background, I was planning to propose that the security doc > keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a > statement that web-based application frameworks SHOULD also support > SDES. (with text about why and how, etc.) Disagree. That leads immediately to half (approximately) of the browser eco= system not supporting SDES. That increases my cost for no true security ben= efit to anyone. >=20 > I don't think this is too controversial, because web-based frameworks are > never beholden to following browser behavior anyway - they're used to > build a native application, and native applications have a very different > security/threat model in practice. They're written for a specific purpos= e, and > installed by users from known sources for that known purpose. Technicall= y, > afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have any > requirements/mandates for native applications anyway - an app maker > would just ignore something they don't think applies to them - but I thin= k > web-based frameworks do generally try to follow W3C models for Javascript > APIs, and will likely read the IETF RFCs for the media-layer stuff too. = So I > think having this SHOULD statement would be beneficial. >=20 > Or if the WG prefers, we could even write a separate doc on what a web- > based framework maker should consider supporting/not-supporting. (I can > imagine a few other things they might want to offer that a browser can't) They might be able to turn ICE off, even! Matthew Kaufman From juberti@google.com Wed Jul 17 13:52:29 2013 Return-Path: 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 E21AC21F9D30 for ; Wed, 17 Jul 2013 13:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 mB+Up-oxb37K for ; Wed, 17 Jul 2013 13:52:14 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id AABB921F9FC8 for ; Wed, 17 Jul 2013 13:52:06 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so5926302wid.3 for ; Wed, 17 Jul 2013 13:52:05 -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=xIb0opwds0tFvYPj5l1fhcvdpSisaYIntBXdJYyLFbg=; b=CK2z3GinCjX0eABj3U/O+VFkyBP7wFhPay0KGRd/FdZbxzjruzugkg3MZgV3kWtQLJ ER3aow2Mzo/6NjTVFuHpSDaA5UGyD8r2AU5BcNcF22EtWsgFVgZRmFi7ulk0q8u+vlFy 1uCPRIA6wDo8i1/1TrpWdkSUBtsGQ+WMiFS1NLmnejujoAt1gzomGfK/taqvkF9Ijunk vagfqEYUqYimklS1a1kddhzB1NsRO1qn73IXP2pcumkoBRjbizwJfHrkG9aMr5oBXFQq X7wi6jgmuKrfizjwQKtPRi9TXspeknnUGImLDQ/F9X/ezbaxjVYZcwKOjdHiPXQiQw6y Esow== 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=xIb0opwds0tFvYPj5l1fhcvdpSisaYIntBXdJYyLFbg=; b=P7jOy+gvSQ4zl2UvMMOg4JbTCKSzJTcz2ikeom53FSSjDidm0JojCBa2NcvmEGZt7v tgc1ld+ZxpWUZOe7nfOcucs5xrVSHvW9IZhU8NV4fisaJLcaIWwWgF3BL5NGVs8QQRbl +mxNEMubbkbGLIxA3FX6H82Qh/uleKj3GMxVtFAL9ZmCzNPkdCQ2J8GJvKOnabE2QpJQ uM2RfL3uyOhj3vOvUCsDkU/K2VMVuJg4aWqd0LN4E7BPiyJ2aPurKK/sYEE8n4LLnZl9 9J7H/5Y44rXzZwysDyieGNkfhCp/RWqQJZqNA6E5NDH9urLiKJGn2l4GUhkIT+2U30jJ jW6g== X-Received: by 10.194.58.239 with SMTP id u15mr6169979wjq.87.1374094325595; Wed, 17 Jul 2013 13:52:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Wed, 17 Jul 2013 13:51:45 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Wed, 17 Jul 2013 16:51:45 -0400 Message-ID: To: Rajmohan Banavi Content-Type: multipart/alternative; boundary=047d7ba97b942a598a04e1bb44fa X-Gm-Message-State: ALoCoQl8Tvvhshjx/pxgKT4SZyGZ+twdcHQuRqr4omeF8RnkLSoTzKrwQDtOew1mC06oP6IzFthb+H/APmrAMauWGSujkeUjv9SVGTvy9KbezYcGWUzT63Tj+HHtABvKdkGMZ91Gafce9wNLIFPfo5r7aimGnhRAhGY9vu3h/UAmhv8V6ZmZFPb1ndS6Q7PLO1uMVIWsI8VH Cc: behave@ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:52:29 -0000 --047d7ba97b942a598a04e1bb44fa Content-Type: text/plain; charset=UTF-8 Thanks for your comments. Responses inline. On Wed, Jul 17, 2013 at 2:56 PM, Rajmohan Banavi wrote: > Hi Justin, > > I reviewed draft-uberti-behave-turn-rest-00 and have the following > comments. > > 1. IMHO, calling the API as REST does not seem to be appropriate since > the API does not follow the REST principles of addressing/operating on a > resource. > > This came up in some earlier rtcweb feedback, but I think it falls within the definition of REST, as it meets the REST design constraints: http://en.wikipedia.org/wiki/**Representational_state_**transfer#Constraints > > 1. Sec 4.3 last paragraph - "Because the password is derived from the > USERNAME, successful verification of the MESSAGE-INTEGRITY ensures that the > username is trustworthy". I believe this validation is taken care of in the > TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN > client generates a long term key which is computed as => key = > MD5(username ":" realm ":" SASLprep(password)). This key is used to perform > hmac on the message. The same is done on the TURN server end as well. If > the MESSAGE-INTEGRITY is verified, then it implies that the username is > trustworthy. So why not just generate a TURN password randomly? This > would avoid the need to have a secret key between the TURN server and the > webrtc app. Am I missing any scenario here where this extra security is > required? > > RFC 5766 doesn't make any guarantees regarding the USERNAME attribute. You know it hasn't been tampered with on the wire, via MESSAGE-INTEGRITY, but you don't know that the USERNAME value is in fact something that the *web server* previously gave out. The construct defines in this draft ties the password to the USERNAME, so that the client cannot change the USERNAME value and still have MESSAGE-INTEGRITY validate properly. This is also why a TURN password can't be generated randomly - the TURN server wouldn't know what random value to use when computing its own MESSAGE-INTEGRITY. > > 1. sec 4.1 Client - Does it make it more clear if we reword the last > sentence as - and the "password" value as input to generate the HMAC digest > key used while calculating MESSAGE-INTEGRITY hash. > > Yes, thanks. > > 1. Sec 5.1 Revocation - Why is revoking of specific credentials not > possible? Probably need more clarity on who would try to revoke the > credentials and under what scenario? > > There is no way to revoke credentials through the REST interface, since there is no communication path between the web server and the TURN server. > > 1. Sec 5.2 Key Rotation - I presume here that the shared secret > mentioned is the one shared between the TURN server and the webrtc > application. The TURN password once generated using say secretkey1 and > user1 will be valid on the TURN server till the expiry timeout (as per > suggested value of 1 day) value. Why do we then need the TURN server to > validate the message integrity against 2 secret keys? Wouldn't this > behavior not contradict the one stated in TURN RFC? > > The lifetime of vended credentials may be 1 day, but if key rotation is performed, sometimes a key rotation will occur during the lifetime of a credential set. As such, the credentials will always need to be validated against secretkey1 (old) and secretkey2(current) until 1 day after the key rotation. > > > Thanks, > Rajmohan > MindBricks > > > On Tue, Jul 16, 2013 at 3:22 AM, Justin Uberti wrote: > >> I have changed the WG for this draft from RTCWEB to BEHAVE. Many, but not >> all of the comments I received on the RTCWEB mailing list have been >> addressed. >> >> BEHAVE chairs, I would like 10 minutes of agenda time to discuss this >> draft. >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Jul 15, 2013 at 5:49 PM >> Subject: New Version Notification for draft-uberti-behave-turn-rest-00.txt >> To: Justin Uberti >> >> >> >> A new version of I-D, draft-uberti-behave-turn-rest-00.txt >> has been successfully submitted by Justin Uberti and posted to the >> IETF repository. >> >> Filename: draft-uberti-behave-turn-rest >> Revision: 00 >> Title: A REST API For Access To TURN Services >> Creation date: 2013-07-15 >> Group: Individual Submission >> Number of pages: 8 >> URL: >> http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-uberti-behave-turn-rest >> Htmlized: >> http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 >> >> >> Abstract: >> This document describes a proposed standard REST API for obtaining >> access to TURN services via ephemeral (i.e. time-limited) >> credentials. These credentials are vended by a web service over >> HTTP, and then supplied to and checked by a TURN server using the >> standard TURN protocol. The usage of ephemeral credentials ensures >> that access to the TURN server can be controlled even if the >> credentials can be discovered by the user, as is the case in WebRTC >> where TURN credentials must be specified in Javascript. >> >> >> >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > -- > > Life is here and now, not yesterday, not tomorrow...! > --047d7ba97b942a598a04e1bb44fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your comments. Responses inline.

On Wed, Jul 17, 2013 at 2:56 PM,= Rajmohan Banavi <rajmohanbanavi@gmail.com> wrote:
Hi Justin,

I reviewed=C2=A0draft-uberti-behav= e-turn-rest-00=C2=A0and have the following = comments.
  1. IMHO, calling the API as REST does not seem to be appropriate since= the API does not follow the REST principles of addressing/operating on a r= esource.
This came up in some earlie= r rtcweb feedback, but I think it falls within the definition of REST, as it meets the REST design constraints:
http://en.wikipedia.org/wiki/Representational_state_tr= ansfer#Constraints
=C2=A0
  1. Sec 4.3 last par= agraph - "Because the password is derived from the USERNAME, successfu= l verification of the MESSAGE-INTEGRITY ensures that the username is trustw= orthy". I believe this validation is taken care of in the TURN RFC its= elf. In order to generate the MESSAGE-INTEGRITY, the TURN client generates = a long term key which is computed as =3D>=C2=A0key =3D MD5(username ":" realm ":" SASLprep(passwo= rd)). This key is used to perform hmac on the message. The same is done on = the TURN server end as well. If the MESSAGE-INTEGRITY is verified, then it = implies that the username is trustworthy. So=C2=A0why not just gener= ate a TURN password randomly? This would avoid the need to have a secret ke= y between the TURN server and the webrtc app. Am I missing any scenario her= e where this extra security is required?
RFC 5766 doesn't make any guarantees= regarding the USERNAME attribute. You know it hasn't been tampered wit= h on the wire, via MESSAGE-INTEGRITY, but you don't know that the USERN= AME value is in fact something that the *web server* previously gave out.= =C2=A0

The construct defines in this draft ties the pass= word to the USERNAME, so that the client cannot change the USERNAME value a= nd still have MESSAGE-INTEGRITY validate properly.

This is also why a TURN password can't be generated randomly - the= TURN server wouldn't know what random value to use when computing its = own MESSAGE-INTEGRITY.
  1. sec 4.1 Client - Does it make it more clear if we reword the last sente= nce as - and the "password" value as input to generate the HMAC d= igest key used while calculating MESSAGE-INTEGRITY hash.
Yes, thanks.=C2=A0
  1. Sec 5.1 Revocation - Why is revoking of specific credentials n= ot possible? Probably need more clarity on who would try to revoke the cred= entials and under what scenario?
There is no way to revoke credentials through the REST interface, since the= re is no communication path between the web server and the TURN server.=C2= =A0
  1. Sec 5.2 Key Rotation - I presume here that the shared secret mentioned = is the one shared between the TURN server and the webrtc application. The T= URN password once generated using say secretkey1 and user1 will be valid on= the TURN server till the expiry timeout (as per suggested value of 1 day) = value. Why do we then need the TURN server to validate the message integrit= y against 2 secret keys? Wouldn't this behavior not contradict the one = stated in TURN RFC?
The lifetime of vended credentials may b= e 1 day, but if key rotation is performed, sometimes a key rotation will oc= cur during the lifetime of a credential set. As such, the credentials will = always need to be validated against secretkey1 (old) and secretkey2(current= ) until 1 day after the key rotation.
Thanks,
Rajmohan
MindBricks


On Tue, Ju= l 16, 2013 at 3:22 AM, Justin Uberti <juberti@google.com> w= rote:
I have changed the = WG for this draft from RTCWEB to BEHAVE. Many, but not all of the comments = I received on the RTCWEB mailing list have been addressed.

BEHAVE chairs, I would like= 10 minutes of agenda time to discuss this draft.

---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
Date: Mon, Jul 15, 2013 at 5:49 PM
Subject: New Version Notification for= draft-uberti-behave-turn-rest-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-behave-turn-rest-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-uberti-behave-turn-rest
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A REST API For Access To TURN Ser= vices
Creation date: =C2=A0 2013-07-15
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 8
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatrack= er.ietf.org/doc/draft-uberti-behave-turn-rest
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h= tml/draft-uberti-behave-turn-rest-00


Abstract:
=C2=A0 =C2=A0This document describes a proposed standard REST API for obtai= ning
=C2=A0 =C2=A0access to TURN services via ephemeral (i.e. time-limited)
=C2=A0 =C2=A0credentials. =C2=A0These credentials are vended by a web servi= ce over
=C2=A0 =C2=A0HTTP, and then supplied to and checked by a TURN server using = the
=C2=A0 =C2=A0standard TURN protocol. =C2=A0The usage of ephemeral credentia= ls ensures
=C2=A0 =C2=A0that access to the TURN server can be controlled even if the =C2=A0 =C2=A0credentials can be discovered by the user, as is the case in W= ebRTC
=C2=A0 =C2=A0where TURN credentials must be specified in Javascript.




The IETF Secretariat




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




--

Life is here and now, not yesterday, not to= morrow...!

--047d7ba97b942a598a04e1bb44fa-- From rajmohanbanavi@gmail.com Wed Jul 17 14:09:16 2013 Return-Path: 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 004BD21E8056; Wed, 17 Jul 2013 14:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2ftoC1RjchGA; Wed, 17 Jul 2013 14:09:15 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B06CE21E8055; Wed, 17 Jul 2013 14:09:14 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so5202767ied.14 for ; Wed, 17 Jul 2013 14:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XSY0uoWPDRiCPpiu9+WoyqJnEG2LNDdqGP3KoTKOass=; b=YAD5I2MF2ICVikl9m+tX4fo93W/h5jBIGI2Ii/bS9q9Xbemz2Hv7XO2VNCElZtdxmn geMBPmVTx+4a5X8ncbURgmTPxuPQXL289UdvBmlXJzkKoLU6G1/O+52QYDlK+xMl/EWQ QAZVlQEpBsCrsTLSj72q1raCfzkkz3XaLdBsIXCQvDCWmqfjygywoHOruNb12ED0KuI1 JgVttTCF93rCNIn5ad5d13TMih3o4hwVddbQ3daHj72nV6IH5TVFZOH+z/7RfbX7gL3g tAeoRgOZx2j2WvzQDH2hAChj2ABTBJBder+NxItoAm17UaaPjsNGZXcIblqE4O4jiKDY EIjw== MIME-Version: 1.0 X-Received: by 10.50.62.75 with SMTP id w11mr2027212igr.19.1374095354174; Wed, 17 Jul 2013 14:09:14 -0700 (PDT) Received: by 10.42.152.9 with HTTP; Wed, 17 Jul 2013 14:09:14 -0700 (PDT) In-Reply-To: <51E70106.8060100@goodadvice.pages.de> References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> Date: Thu, 18 Jul 2013 02:39:14 +0530 Message-ID: From: Rajmohan Banavi To: Philipp Hancke Content-Type: multipart/alternative; boundary=047d7bdc10e47923a204e1bb811b Cc: behave@ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:09:16 -0000 --047d7bdc10e47923a204e1bb811b Content-Type: text/plain; charset=ISO-8859-1 Thanks for the detailed example. I agree with the entire flow you have given. My only concern is - why should the ephemeral password be generated by TURN server using HMAC SHA on then username string? Why can't this be some random unique string? Taking your example - Suppose TURN server generates credentials, username = "12334939:mbzrxpgjys" and password ="+somerandomstring+". This is a randomly generated string and passed onto webrtc app. The TURN server also stores these credentials for later validation. var iceServer = { "username": 12334939:mbzrxpgjys, "credential": +somerandomstring+, }; These credentials are passed from JS to the webrtc client stack in the browser. On Browser WebTRC Client. key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+) Similarly on the TURN server, the key for MESSAGE-INTEGRITY is calculated using key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+) So the browser and turn server use the same input to the M-I. The one implementation related advantage I see with this way of generation of TURN password using HMAC is that the TURN server need not really store the HMAC generated password, but can calculate the same using the USERNAME attribute in the received TURN request. In fact, I do not see why the sharedsecret needs to be shared between the TURN server and the WebRTC application. The sharedsecret key "secret" is only required by the TURN server for validating the received TURN ALLOCATE requests once it has generated and sent out the ephemeral credentials. What does the WebRTC application do with the shared secret key? Thanks, Rajmohan On Thu, Jul 18, 2013 at 2:09 AM, Philipp Hancke wrote: > Am 17.07.2013 20:56, schrieb Rajmohan Banavi: > > Hi Justin, >> >> I reviewed draft-uberti-behave-turn-rest-**00 and have the following >> comments. >> > [...] > >> 2. Sec 4.3 last paragraph - "Because the password is derived from the >> >> USERNAME, successful verification of the MESSAGE-INTEGRITY ensures >> that the >> username is trustworthy". I believe this validation is taken care of >> in the >> TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN >> client generates a long term key which is computed as => key = >> MD5(username ":" realm ":" SASLprep(password)). This key is used to >> perform >> hmac on the message. The same is done on the TURN server end as well. >> If >> the MESSAGE-INTEGRITY is verified, then it implies that the username >> is >> trustworthy. >> > > Let me try to address that with a lenghty example: > The web server returns > password = BASE64(HMAC-SHA1(username, sharedsecret)) > to the browser. > > For example, with username = "12334939:mbzrxpgjys" and sharedsecret > "secret", the password given to the browser would be > "+4pCXR06gx/cqAikLYnBajtZW6E=" (hopefully) > > > > > The browser passes the username, uri and password to it's webrtc stack. > The password is exposed to the user of the browser (which might be anyone > surfing your website) during that process. > > That stack does long term authentication and uses this password string as > input for calculating MESSAGE-INTEGRITY with > key = MD5(username ":" realm ":" SASLprep(password)) > > For the example this would be > key =MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/** > cqAikLYnBajtZW6E=") > > > > > On the TURN server, the key for MESSAGE-INTEGRITY is calculated using > key = MD5(username ":" realm ":" SASLprep(BASE64(HMAC-SHA1(**USERNAME, > sharedsecret)) > > So for the example this would be > = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep(BASE64(HMAC-SHA1("**12334939:mbzrxpgjys", > "secret")) > = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/** > cqAikLYnBajtZW6E=") > > So the browser and turn server use the same input to the M-I. This can be > done by looking at the request alone given the shared secret. > > > Does that make it clearer? > > philipp, > who only understood it after implementing it > -- Life is here and now, not yesterday, not tomorrow...! --047d7bdc10e47923a204e1bb811b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the detailed example. I agree with the entire f= low you have given. My only concern is - why should the ephemeral password = be generated by TURN server using HMAC SHA on then username string? Why can= 't this be some random unique string?

Taking your example -=A0

Suppose= TURN server generates credentials, username =3D "12334939:mbzrxpgjys&= quot; and password =3D"+somerandomstring+". This is a randomly generated = string and passed onto webrtc app. The TURN server also stores these creden= tials for later validation.
var iceServer =3D {
= =A0 =A0 =A0"username":=A0= 12334939:mbzrxp= gjys,
=A0 =A0 =A0"credential":=A0= +someran= domstring+,
=A0 =A0};

These credentials are passed from JS to the webrtc clien= t stack in the browser.

On= Browser WebTRC Client.=A0
key =3D MD5(12334939:mbzrxpgjys=A0":" realm &q= uot;:"=A0+somerandomstring+)
Simi= larly on the TURN server, the key for MESSAGE-INTEGRITY is calculated using=
key =3D MD5(12334939:mbzrxpgjys=A0":= " realm ":"=A0+somerandomstring+)

So the browser and turn server u= se the same input to the M-I. The one implementation related advantage I se= e with this way of generation of TURN password using HMAC is that the TURN = server need not really store the HMAC generated password, but can calculate= the same using the USERNAME attribute in the received TURN request.=

=
In fact, I do not see why the sharedsecret needs to be shared betw= een the TURN server and the WebRTC application. The sharedsecret key "= secret" is only required by the TURN server for validating the receive= d TURN ALLOCATE requests once it has generated and sent out the ephemeral c= redentials. What does the WebRTC application do with the shared secret key?=

Thanks,
Rajmohan


On Thu,= Jul 18, 2013 at 2:09 AM, Philipp Hancke <fippo@goodadvice.pages.d= e> wrote:
Am 17.07.2013 20:56, schrieb Rajmohan Banavi= :

Hi Justin,

I reviewed draft-uberti-behave-turn-rest-00 and have the following c= omments.
[...]
=A0 =A0 2. Sec 4.3 last paragraph - "Because the password is derived f= rom the

=A0 =A0 USERNAME, successful verification of the MESSAGE-INTEGRITY ensures = that the
=A0 =A0 username is trustworthy". I believe this validation is taken c= are of in the
=A0 =A0 TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TU= RN
=A0 =A0 client generates a long term key which is computed as =3D> key = =3D
=A0 =A0 MD5(username ":" realm ":" SASLprep(password)).= This key is used to perform
=A0 =A0 hmac on the message. The same is done on the TURN server end as wel= l. If
=A0 =A0 the MESSAGE-INTEGRITY is verified, then it implies that the usernam= e is
=A0 =A0 trustworthy.

Let me try to address that with a lenghty example:
The web server returns
password =3D BASE64(HMAC-SHA1(username, sharedsecret))
to the browser.

For example, with username =3D "12334939:mbzrxpgjys" and sharedse= cret "secret", the password given to the browser would be
"+4pCXR06gx/cqAikLYnBajtZW6E=3D" (hopefully)




The browser passes the username, uri and password to it's webrtc stack.=
The password is exposed to the user of the browser (which might be anyone s= urfing your website) during that process.

That stack does long term authentication and uses this password string as i= nput for calculating MESSAGE-INTEGRITY with
key =3D MD5(username ":" realm ":" SASLprep(password))<= br>
For the example this would be
key =3DMD5("12334939:mbzrxpgjys" ":" realm ":"= ; SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=3D")




On the TURN server, the key for MESSAGE-INTEGRITY is calculated using
key =3D MD5(username ":" realm ":" SASLprep(BASE64(HMAC= -SHA1(USERNAME, sharedsecret))

So for the example this would be
=A0=3D MD5("12334939:mbzrxpgjys" ":" realm ":"= ; SASLprep(BASE64(HMAC-SHA1("12334939:mbzrxpgjys", "s= ecret"))
=A0=3D MD5("12334939:mbzrxpgjys" ":" realm ":"= ; SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=3D")

So the browser and turn server use the same input to the M-I. This can be d= one by looking at the request alone given the shared secret.


Does that make it clearer?

philipp,
who only understood it after implementing it



--

Life is = here and now, not yesterday, not tomorrow...!
--047d7bdc10e47923a204e1bb811b-- From matthew.kaufman@skype.net Wed Jul 17 14:31:19 2013 Return-Path: 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 F0D4B21F9E36 for ; Wed, 17 Jul 2013 14:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=-0.282, 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 r3R2Xf1fa4wa for ; Wed, 17 Jul 2013 14:31:13 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id A76A321F9A05 for ; Wed, 17 Jul 2013 14:31:03 -0700 (PDT) Received: from mail60-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE011.bigfish.com (10.174.4.74) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 21:31:02 +0000 Received: from mail60-db8 (localhost [127.0.0.1]) by mail60-db8-R.bigfish.com (Postfix) with ESMTP id 0F821300419; Wed, 17 Jul 2013 21:31:02 +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: 0 X-BigFish: VS0(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail60-db8: 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 mail60-db8 (localhost.localdomain [127.0.0.1]) by mail60-db8 (MessageSwitch) id 1374096584689247_27675; Wed, 17 Jul 2013 21:29:44 +0000 (UTC) Received: from DB8EHSMHS012.bigfish.com (unknown [10.174.8.250]) by mail60-db8.bigfish.com (Postfix) with ESMTP id 5BBD3B80053; Wed, 17 Jul 2013 21:29:44 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB8EHSMHS012.bigfish.com (10.174.4.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 17 Jul 2013 21:29:42 +0000 Received: from TK5EX14MBXC265.redmond.corp.microsoft.com ([169.254.3.88]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0136.001; Wed, 17 Jul 2013 21:29:04 +0000 From: "Matthew Kaufman (SKYPE)" To: Ted Hardie , "public-webrtc@w3.org" Thread-Topic: [rtcweb] Locus of API discussion Thread-Index: AQHOfLmwMutMwraSzEud0Hjh6FFtPplpbmzw Date: Wed, 17 Jul 2013 21:29:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] 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: "rtcweb@ietf.org" Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:31:20 -0000 Ted Hardie: Howdy, The recent set of API discussions has been spread across both the rtcweb a= nd public-webrtc mailing lists.=A0 That's making it both harder to follow a= nd harder for folks to work out who is saying what under which rules.=A0 The chairs of both groups bel= ieve that the right place for the discussion to continue should be public-w= ebrtc.=A0 Please direct follow- ups on this topic to that list. Does that include moving the SDP "API surface" discussions and decisions to= the public-webrtc mailing lists?=20 I am frankly quite concerned given earlier comments that yes, the W3C had g= iven responsibility for "JSEP" and the resulting SDP work to IETF, and so n= ow we have the IETF WG making decisions but the discussion happening on the= W3C list -- which means there's no "paper trail" prior to the IETF meeting= on an IETF list about how the participants have weighed in -- and then con= versely when the W3C spec gets to last call there will be no "paper trail" = at the W3C showing how decisions had been reached about the SDP "API", as t= hat happened over in the MMUSIC WG, which list was not even copied on this = message. Matthew Kaufman From creslin@digium.com Wed Jul 17 14:50:27 2013 Return-Path: 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 6A33921F9D75 for ; Wed, 17 Jul 2013 14:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 MV4bn1pmt7zG for ; Wed, 17 Jul 2013 14:50:17 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 28DAA21F9D2A for ; Wed, 17 Jul 2013 14:50:16 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id y6so1921840lbh.23 for ; Wed, 17 Jul 2013 14:50:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pjySF9oCt6W2qYcA7EpkCTQElOzoo0IXDf95m3TMsks=; b=fK/fzzevUSBW1V7sGfmldBO89S0oc/1mVQs+Q8xEkvEeZW/82ct00eNKgNIT5842CB i6HzA62dp4gyot0POy41tP8Aq7khX6iUORYjZ7kREpPDb5dQzfNLZdBwz5SdMN0ysNlJ gGRkA6LGc/3DhsQ7som7eVgPLhHhyz0cyUNmO3tl/OsOIWCOh8QF97sOMlNz0EDwsiJl kHVb5Zx/wcyUHacp+uAehM7buI4lqJYltOflN0TX/16MOqDWl6DZEdp8aWCZaBOvFx8g aEYHkKb9+MdwJ1N0jb2qkudcCwt9odDWYRSoF861dY6j6HdlXlWZvJmHzrCBgg0m9uoL jWLA== MIME-Version: 1.0 X-Received: by 10.112.198.230 with SMTP id jf6mr4127188lbc.11.1374097408868; Wed, 17 Jul 2013 14:43:28 -0700 (PDT) Received: by 10.112.141.161 with HTTP; Wed, 17 Jul 2013 14:43:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 16:43:28 -0500 Message-ID: From: Matt Fredrickson To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=001a11c27cacf1530004e1bbfb05 X-Gm-Message-State: ALoCoQlKktQR5RQE/zN5X/tzTEKMu8HS0tslZGHIcr/kACdoH90mIlaWa9ATg84WxjXn2kvp9wGC Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:50:27 -0000 --001a11c27cacf1530004e1bbfb05 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 17, 2013 at 3:48 PM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > Hadriel Kaplan: > > > > Howdy, > > Someone's asked me to explain the compromise I plan on presenting in > > Berlin now, so we have more time to argue over it or chew on it. The > reason > > I was going to wait is because I wanted to explain how I got to the > point of > > thinking such a compromise would make sense. So I'll try to do that in > this > > email, which will make this email long. Nothin' much I can do about > that. > > > > Obviously this is all my personal opinion, not that of my employer, and > not a > > statement claiming to be objective fact, etc. > > Likewise, in this reply where, though I like you, I don't like your > proposal. > > > > > Background: > > I think many people would agree that SDES has some benefits compared to > > DTLS for those of us wishing to interface to the SIP world. Some of > those > > benefits are commercial/cost factors, some are more tangible like > reducing > > early media clipping. Whether you agree with such benefits or not, so > long as > > WebRTC could support SDES in a sufficiently-secure manner, there'd be > less > > concern over having it. Most of the arguments against SDES have been > > directed at whether it could in fact be "sufficiently secure". > Personally I find > > most of the arguments against it being secure enough to be essentially > FUD, > > and/or also apply to DTLS-SRTP. > > I believe that once the entire system is considered, any system that > allows EKT shares the same security properties as one that allows SDES, and > one that does not allow EKT requires a decrypt/re-encrypt phase at the > gateway that is costly. > > > > > On the flip-side, I think the commercial/cost factor for SDES is not a > strong > > cause, because I believe the market will bear whatever the extra cost may > > be. (I wasn't sure of this 2 years ago when this all started, but I'm > fairly > > confident of it now) And I think having only DTLS-SRTP as MTI would > have a > > marketing benefit for WebRTC as a technology, which I value highly. > > The market might bear the extra cost, but it doesn't mean that it isn't > extra cost (and extra environmental damage through the extra energy > consumed). > > > > > Given those personal feelings, I didn't much care either way, so long as > a > > decision was made - although I still preferred having SDES to avoid the > early > > media clipping problem. So when I was going to present on this topic > back in > > the Vancouver meeting, my last slide basically said: "If we support SDES > and it > > turns out later we were wrong, we can always rescind it". This was > based on > > the notion that browsers get updated all the time, especially for > security > > issues. > > > > But later it occurred to me that's actually the Achilles' heel of > supporting SDES > > in WebRTC, for those of us wanting to gateway this stuff to SIP. > Imagine if it > > turns out we were wrong, and some expected-or-unexpected vulnerability is > > exploited against some large WebRTC service provider, and makes the > > news/slashdot. Browser vendors would instantly have new code removing > > SDES support, and browsers in devices would be updated virtually > overnight - > > some users may take a long time to upgrade their specific browsers on > their > > specific devices - but many of them would do so within days. That would > be > > untenable for a WebRTC service provider. > > I can't imagine such a scenario that couldn't also happen with DTLS-SRTP, > especially DTLS-SRTP + EKT. > > Plus there's lots of counterexamples where major sites have been > compromised in ways that could have been fixed browser-side, and yet > browsers didn't bother to update. > > And finally, what makes you think that the browser vendors would do > something like that if the service really was popular? I guess if Google > and Mozilla wanted everyone using Skype to switch to Internet Explorer they > could pull such a stunt, but why? (In a hypothetical future where IE has > webrtc support and Skype supports webrtc-equipped browsers as a platform > for calling, of course) > > > Even the smaller Enterprises take > > a long time to upgrade code on their servers, so even for them changing > their > > gateways to suddenly support DTLS-SRTP would be unrealistic. Imagine > what > > it would be for larger providers, who might even have to deploy more > > servers to handle the sudden additional overhead of DTLS-SRTP. Meanwhile > > a growing perc entage of their users can no longer use the service. > That's > > bad mojo. > > I argue that it'd never happen. > > > > > The things that a WebRTC-to-SIP service provider can control, and > arguably > > the much larger use-case for this stuff to begin with, are not really > true > > "browsers" anyway - they're web-based-framework device Apps, provided > > by the service provider to begin with. I.e., the apps they build using > web > > application framework things like PhoneGap/Cordova, Appcelerator > > Titanium, etc. I mean using a real Browser is nice for ad-hoc stuff, > like being > > able to click on a "talk to a rep" button on a website, or a > webex/meetecho > > type thing; but for real communication "service", whether it be as a > > subscriber of a traditional carrier, or Skype, or an employee of an > Enterprise, > > or a call-center attendant, or whatever - for those most people would > never > > want to have to open a browser just to receive/make calls. They'd give > you > > an app to use instead. > > > > So it's the app use-case that would benefit the most from SDES, > especially for > > issues like media clipping. And the app use-case doesn't have the > security > > concerns nor concerns for unforeseen overnight updates. > > > And will probably support SDES. > > > > > The Compromise: > > So given that background, I was planning to propose that the security doc > > keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a > > statement that web-based application frameworks SHOULD also support > > SDES. (with text about why and how, etc.) > > Disagree. That leads immediately to half (approximately) of the browser > ecosystem not supporting SDES. That increases my cost for no true security > benefit to anyone. > > > > > I don't think this is too controversial, because web-based frameworks are > > never beholden to following browser behavior anyway - they're used to > > build a native application, and native applications have a very different > > security/threat model in practice. They're written for a specific > purpose, and > > installed by users from known sources for that known purpose. > Technically, > > afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have any > > requirements/mandates for native applications anyway - an app maker > > would just ignore something they don't think applies to them - but I > think > > web-based frameworks do generally try to follow W3C models for Javascript > > APIs, and will likely read the IETF RFCs for the media-layer stuff too. > So I > > think having this SHOULD statement would be beneficial. > > > > Or if the WG prefers, we could even write a separate doc on what a web- > > based framework maker should consider supporting/not-supporting. (I can > > imagine a few other things they might want to offer that a browser can't) > > > They might be able to turn ICE off, even! > Amen. I think ICE will be the first barrier to initiating communications with legacy equipment anyways... Anybody that can get past the ICE step will then be allowed to deal with the problems of the mandatorily included encryption mechanisms as a next step. I don't know if there is very much "legacy" equipment that will be able to interop with WebRTC media sessions without some sort of translation. Matthew Fredrickson --001a11c27cacf1530004e1bbfb05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 17, 2013 at 3:48 PM, Matthew Kaufman (SKYPE) <= span dir=3D"ltr"><matthew.kaufman@skype.net> wrote:
Hadriel Kaplan:
>
> Howdy,
> Someone's asked me to explain the compromise I plan on presenting = in
> Berlin now, so we have more time to argue over it or chew on it. =A0Th= e reason
> I was going to wait is because I wanted to explain how I got to the po= int of
> thinking such a compromise would make sense. =A0So I'll try to do = that in this
> email, which will make this email long. =A0Nothin' much I can do a= bout that.
>
> Obviously this is all my personal opinion, not that of my employer, an= d not a
> statement claiming to be objective fact, etc.

Likewise, in this reply where, though I like you, I don't like yo= ur proposal.

>
> Background:
> I think many people would agree that SDES has some benefits compared t= o
> DTLS for those of us wishing to interface to the SIP world. =A0Some of= those
> benefits are commercial/cost factors, some are more tangible like redu= cing
> early media clipping. =A0Whether you agree with such benefits or not, = so long as
> WebRTC could support SDES in a sufficiently-secure manner, there'd= be less
> concern over having it. =A0Most of the arguments against SDES have bee= n
> directed at whether it could in fact be "sufficiently secure"= ;. =A0Personally I find
> most of the arguments against it being secure enough to be essentially= FUD,
> and/or also apply to DTLS-SRTP.

I believe that once the entire system is considered, any system that = allows EKT shares the same security properties as one that allows SDES, and= one that does not allow EKT requires a decrypt/re-encrypt phase at the gat= eway that is costly.

>
> On the flip-side, I think the commercial/cost factor for SDES is not a= strong
> cause, because I believe the market will bear whatever the extra cost = may
> be. (I wasn't sure of this 2 years ago when this all started, but = I'm fairly
> confident of it now) =A0And I think having only DTLS-SRTP as MTI would= have a
> marketing benefit for WebRTC as a technology, which I value highly.
The market might bear the extra cost, but it doesn't mean that it= isn't extra cost (and extra environmental damage through the extra ene= rgy consumed).

>
> Given those personal feelings, I didn't much care either way, so l= ong as a
> decision was made - although I still preferred having SDES to avoid th= e early
> media clipping problem. =A0So when I was going to present on this topi= c back in
> the Vancouver meeting, my last slide basically said: "If we suppo= rt SDES and it
> turns out later we were wrong, we can always rescind it". =A0This= was based on
> the notion that browsers get updated all the time, especially for secu= rity
> issues.
>
> But later it occurred to me that's actually the Achilles' heel= of supporting SDES
> in WebRTC, for those of us wanting to gateway this stuff to SIP. =A0Im= agine if it
> turns out we were wrong, and some expected-or-unexpected vulnerability= is
> exploited against some large WebRTC service provider, and makes the > news/slashdot. =A0Browser vendors would instantly have new code removi= ng
> SDES support, and browsers in devices would be updated virtually overn= ight -
> some users may take a long time to upgrade their specific browsers on = their
> specific devices - but many of them would do so within days. =A0That w= ould be
> untenable for a WebRTC service provider.

I can't imagine such a scenario that couldn't also happen wit= h DTLS-SRTP, especially DTLS-SRTP + EKT.

Plus there's lots of counterexamples where major sites have been compro= mised in ways that could have been fixed browser-side, and yet browsers did= n't bother to update.

And finally, what makes you think that the browser vendors would do somethi= ng like that if the service really was popular? I guess if Google and Mozil= la wanted everyone using Skype to switch to Internet Explorer they could pu= ll such a stunt, but why? (In a hypothetical future where IE has webrtc sup= port and Skype supports webrtc-equipped browsers as a platform for calling,= of course)

> Even the smaller Enterprises take
> a long time to upgrade code on their servers, so even for them changin= g their
> gateways to suddenly support DTLS-SRTP would be unrealistic. =A0Imagin= e what
> it would be for larger providers, who might even have to deploy more > servers to handle the sudden additional overhead of DTLS-SRTP. =A0Mean= while
> a growing perc =A0entage of their users can no longer use the service.= =A0That's
> bad mojo.

I argue that it'd never happen.

>
> The things that a WebRTC-to-SIP service provider can control, and argu= ably
> the much larger use-case for this stuff to begin with, are not really = true
> "browsers" anyway - they're web-based-framework device A= pps, provided
> by the service provider to begin with. =A0I.e., the apps they build us= ing web
> application framework things like PhoneGap/Cordova, Appcelerator
> Titanium, etc. =A0I mean using a real Browser is nice for ad-hoc stuff= , like being
> able to click on a "talk to a rep" button on a website, or a= webex/meetecho
> type thing; but for real communication "service", whether it= be as a
> subscriber of a traditional carrier, or Skype, or an employee of an En= terprise,
> or a call-center attendant, or whatever - for those most people would = never
> want to have to open a browser just to receive/make calls. =A0They'= ;d give you
> an app to use instead.
>
> So it's the app use-case that would benefit the most from SDES, es= pecially for
> issues like media clipping. =A0And the app use-case doesn't have t= he security
> concerns nor concerns for unforeseen overnight updates.


And will probably support SDES.

>
> The Compromise:
> So given that background, I was planning to propose that the security = doc
> keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a > statement that web-based application frameworks SHOULD also support > SDES. (with text about why and how, etc.)

Disagree. That leads immediately to half (approximately) of the brows= er ecosystem not supporting SDES. That increases my cost for no true securi= ty benefit to anyone.

>
> I don't think this is too controversial, because web-based framewo= rks are
> never beholden to following browser behavior anyway - they're used= to
> build a native application, and native applications have a very differ= ent
> security/threat model in practice. =A0They're written for a specif= ic purpose, and
> installed by users from known sources for that known purpose. =A0Techn= ically,
> afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have any > requirements/mandates for native applications anyway - an app maker > would just ignore something they don't think applies to them - but= I think
> web-based frameworks do generally try to follow W3C models for Javascr= ipt
> APIs, and will likely read the IETF RFCs for the media-layer stuff too= . =A0So I
> think having this SHOULD statement would be beneficial.
>
> Or if the WG prefers, we could even write a separate doc on what a web= -
> based framework maker should consider supporting/not-supporting. (I ca= n
> imagine a few other things they might want to offer that a browser can= 't)


They might be able to turn ICE off, even!

Amen. =A0I think ICE will be the first barrier to initiating commu= nications with legacy equipment anyways... Anybody that can get past the IC= E step will then be allowed to deal with the problems of the mandatorily in= cluded encryption mechanisms as a next step.

I don't know if there is very much "legacy&quo= t; equipment that will be able to interop with WebRTC media sessions withou= t some sort of translation.


Matthew= Fredrickson
--001a11c27cacf1530004e1bbfb05-- From matthew.kaufman@skype.net Wed Jul 17 14:59:53 2013 Return-Path: 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 DB41D21F9DFA for ; Wed, 17 Jul 2013 14:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.761 X-Spam-Level: X-Spam-Status: No, score=-3.761 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, 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 5bsdz+rSFQ32 for ; Wed, 17 Jul 2013 14:59:44 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5088221F9E26 for ; Wed, 17 Jul 2013 14:59:44 -0700 (PDT) Received: from mail86-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE007.bigfish.com (10.236.130.70) with Microsoft SMTP Server id 14.1.225.22; Wed, 17 Jul 2013 21:59:43 +0000 Received: from mail86-co9 (localhost [127.0.0.1]) by mail86-co9-R.bigfish.com (Postfix) with ESMTP id 94B304E0077; Wed, 17 Jul 2013 21:59:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail86-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=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail86-co9 (localhost.localdomain [127.0.0.1]) by mail86-co9 (MessageSwitch) id 1374098381101368_23104; Wed, 17 Jul 2013 21:59:41 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.248]) by mail86-co9.bigfish.com (Postfix) with ESMTP id 146E24C0049; Wed, 17 Jul 2013 21:59:41 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 17 Jul 2013 21:59:35 +0000 Received: from TK5EX14MBXC265.redmond.corp.microsoft.com ([169.254.3.88]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Wed, 17 Jul 2013 21:58:37 +0000 From: "Matthew Kaufman (SKYPE)" To: Bernard Aboba , =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOgoLR5V+chGbsUEageQv6sS/XzplpaE4A Date: Wed, 17 Jul 2013 21:58:37 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:59:53 -0000 QmVybmFyZCBBYm9iYToNCj4gDQo+IFRoZSBwcm9ibGVtIHdhcyB0aGF0IHdlIG5ldmVyIGRlZmlu ZWQgd2hhdCBtYW5nbGluZyBicm93c2VycyBoYWQgdG8NCj4gc3VwcG9ydC4gR2l2ZW4gYWxsIHRo ZSBTRFAgc3BlY3MgdGhhdCBpcyBhY3R1YWxseSBhIGh1Z2Ugd29yayBpdGVtLg0KDQoNClRoaXMg aXMgZXhhY3RseSB3aGF0IG15IHNsaWRlcyB0aGF0IHdlcmVuJ3QgcHJlc2VudGVkIGxhc3QgTm92 ZW1iZXIgc3RhcnRlZCB0byB0b3VjaCB1cG9uLiBJdCBvbmx5IHRha2VzIGEgZmV3IG1pbnV0ZXMg d2l0aCBSRkMzMjY0IGFuZCBpdHMgcmVmZXJlbmNlcyB0byBzdGFydCBkb2N1bWVudGluZyBjYXNl cyB0aGF0IGFyZSBjbGVhcmx5ICJ2YWxpZCBTRFAgb2ZmZXIvYW5zd2VyIiBhbmQgeWV0IGZvciB3 aGljaCBJIGNhbm5vdCBmb3IgdGhlIGxpZmUgb2YgbWUgZmlndXJlIG91dCB3aGF0IGEgYnJvd3Nl ciBzaG91bGQgZG8gaWYgdGhleSdyZSBwcmVzZW50ZWQuDQoNCkp1c3Qgb2ZmIHRoZSB0b3Agb2Yg bXkgaGVhZDoNCg0KQ2FuIEkuLi4NCi0gQ2hhbmdlIHRoZSB0PSBsaW5lIHRvIGJlIHNvbWV0aGlu ZyBvdGhlciB0aGFuIHQ9MCAwPw0KLSBDaGFuZ2UgdGhlIHJ0cG1hcCBhc3NvY2lhdGlvbnMgYmVm b3JlIGNhbGxpbmcgc2V0TG9jYWw/DQotIENoYW5nZSBhPXNlbmRyZWN2IHRvIGE9cmVjdm9ubHkg YmVmb3JlIGNhbGxpbmcgc2V0TG9jYWw/DQotIFdoYXQgZG8geW91IGRvIHdoZW4geW91IHNlZSBh PWNvbnRlbnQ6c2wgPw0KLSBXaGF0IGlmIHNvbWVvbmUgYWRkcyBhbiByPSBvciBwPSBvciBlPT8N Ci0gV2hhdCBpcyB0aGUgUkZDIHRoYXQgZGVzY3JpYmVzIGE9Z3JvdXA6QlVORExFIChhcyBzZWVu IGluIHNvbWUgYnJvd3NlciBpbXBsZW1lbnRhdGlvbnMpPw0KLSBDYW4gSSByZW1vdmUgYT1ncm91 cDpCVU5ETEUgKG9yIGFkZCBpdCkgYmVmb3JlIGNhbGxpbmcgc2V0TG9jYWw/DQotIEhvdyBhYm91 dCByZW1vdmluZyBhPXJ0Y3AtbXV4Pw0KLSBTaG91bGQgSSBkbyBzb21ldGhpbmcgc3BlY2lhbCBh dCBteSBlbmQgaWYgeW91IHNldCBhPWljZS1vcHRpb25zOmdvb2dsZS1pY2UgPw0KLSBJZiB5b3Ug cHV0IGE9c3NyYyBsaW5lcyBpbiB0aGVyZSwgY2FuIEkgY2hhbmdlIHRoZSBzc3JjIGJlZm9yZSBw YXNzaW5nIGl0IGJhY2sgdG8gc2V0TG9jYWw/DQotIENhbiBJIGRlbGV0ZSB0aGUgYT1zc3JjIGxp bmVzPw0KLSBJcyBhPXJ0Y3A6MSBJTiBJUDQgMC4wLjAuMCB2YWxpZCBvciBub3Q/DQotIFdoYXQg YWJvdXQgMC4wLjAuMCBpbiB0aGUgbz0gbGluZT8NCi0gSWYgSSBnZXQgYSBidW5jaCBvZiBhPWNh bmRpZGF0ZSBsaW5lcywgY2FuIEkgc3dhcCB0aGVtIGFyb3VuZCB0byBjaGFuZ2UgdGhlIHByaW9y aXR5IGJlZm9yZSBjYWxsaW5nIHNldExvY2FsPw0KLSBXaGF0IGlmIHNvbWVvbmUgY2xhaW1zIFNB VlAgaW5zdGVhZCBvZiBTQVZQRiBidXQgZ2l2ZXMgbWUgcnRjcCBpbmZvPw0KCQ0KQXQgdGhlICp2 ZXJ5IGxlYXN0KiBmb3IgZWFjaCBhbmQgZXZlcnkgbGluZSB0aGF0IGNvbWVzIGZyb20gY3JlYXRl T2ZmZXIgYW5kIGNyZWF0ZUFuc3dlciB5b3UgbXVzdCBiZSBhYmxlIHRvIGFuc3dlciB0aGUgZm9s bG93aW5nOg0KLSBDYW4gSSBkZWxldGUgaXQ/DQotIER1cGxpY2F0ZSBpdD8NCi0gQ2hhbmdlIGl0 Pw0KLSBJZiBub3QsIGhvdyBhcmUgdmlvbGF0aW9uIGhhbmRsZWQ/IChCb3RoIHdoZW4gcGFzc2Vk IHRvIGFub3RoZXIgYnJvd3NlciBhdCB0aGUgZmFyIGVuZCBhbmQgd2hlbiB0aGVzZSBtb2RpZmlj YXRpb25zIGhhcHBlbiBiZWZvcmUgY2FsbGluZyBzZXRMb2NhbCkNCiAtIEFuZCBjYW4gSSBhZGQg YWRkaXRpb25hbCB2YWxpZCBTRFAgdG8gd2hhdCBjYW1lIGZyb20gY3JlYXRlT2ZmZXIgb3IgY3Jl YXRlQW5zd2VyIGFuZCBwYXNzIGl0IGJhY2sgdG8gc2V0TG9jYWwgb3Igbm90Pw0KDQpXZSBhcHBl YXIgdG8gYmUgbm93aGVyZSBuZWFyIGEgZG9jdW1lbnQgd2hpY2ggZXhwbGFpbnMgdGhlIGFuc3dl cnMgdG8gdGhlc2UgcXVlc3Rpb25zLCBjZXJ0YWlubHkgbm90IGluIHRoZSBXM0MgV0csIGFuZCBu b3QgaW4gYW55IElFVEYgUkZDIG9yIGRyYWZ0IEkgY2FuIGxvY2F0ZS4NCg0KTWF0dGhldyBLYXVm bWFuDQoNCg== From ekr@rtfm.com Wed Jul 17 15:00:27 2013 Return-Path: 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 7228321F9E26 for ; Wed, 17 Jul 2013 15:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 B25dvCT5pxjm for ; Wed, 17 Jul 2013 15:00:21 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDA821F9DFA for ; Wed, 17 Jul 2013 15:00:21 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id j10so1400864qcx.3 for ; Wed, 17 Jul 2013 15:00:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=1kl0FiMgbzIOlmmkviZphtkH32h7K+ZXj5O3h1Rmku4=; b=DkRqf3+5qec73pjsf994MPJ7BgVT35r+BKDJkafC/ZxfvLZNlBKrcr43OKMcX4LSe2 2G9fmxnam30VVDR67qF5co8jON9PbU523TsBBr8c9YTyjlDimCWBKBul6AysmaRHe/iN sPqij0QdguF5naqhmyhil3hSSsGAo8FWBrrXs/mgtqXdG5fwd651ai1ywULzOvpfSYyR x29cPE8P1OI7BbuN8I+WtLyMOkPNSJn6vt5coHc+voUCvlpp1LJU/3r8v7GrApBEnu8k DBUpZdW689THbRFat86aBImPcGq+vLf/qdO+Aq2WlI2ej+er3B6xrgafKaHvx3NrjUIT SZaw== X-Received: by 10.49.85.4 with SMTP id d4mr10169429qez.10.1374098420747; Wed, 17 Jul 2013 15:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 17 Jul 2013 14:59:40 -0700 (PDT) X-Originating-IP: [203.69.99.16] In-Reply-To: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> From: Eric Rescorla Date: Thu, 18 Jul 2013 05:59:40 +0800 Message-ID: To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=047d7bb03e6a41619d04e1bc38e6 X-Gm-Message-State: ALoCoQm/BqeeFQGO/IvO6qZOvu4aLNMn1+KJFW+MWqK0fstybeY/j8pDwRm/afTA6XnIdS1H1N/U Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:00:27 -0000 --047d7bb03e6a41619d04e1bc38e6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 8:47 PM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > |Uh, then how would they be sent to the other side?**** > > ** ** > > Ah, the browser would have to modify the SDP when it is sent on the wire.= . > I don't really see how this helps since the server is going to see it and call tell the JS (remember, that's where the JS came from). -Ekr > > |As far as I can tell, with any plausible API SDES requires exposing the > keys to JS.**** > > ** ** > > That helps..thanks.**** > > ** ** > > Muthu**** > > ** ** > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Wednesday, July 17, 2013 2:32 PM > *To:* Muthu Arul Mozhi Perumal (mperumal) > *Cc:* Simon Perreault; behave@ietf.org; rtcweb@ietf.org > *Subject:* Re: [rtcweb] [BEHAVE] FW: I-D Action: > draft-muthu-behave-consent-freshness-04.txt**** > > ** ** > > ** ** > > ** ** > > On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal) < > mperumal@cisco.com> wrote:**** > > [Added rtcweb since I am not sure if everyone involved there are followin= g > this discussion in behave] > > Thanks for the review. See inline.. > > |-----Original Message----- > |From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Simon Perreault > |Sent: Tuesday, July 16, 2013 3:05 PM > |To: behave@ietf.org > |Subject: Re: [BEHAVE] FW: I-D Action: > draft-muthu-behave-consent-freshness-04.txt > | > |Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit :**** > > |> The text and the algorithm in the draft are significantly simplified i= n > this updated version. > |> > |> Comments welcome.. > |**** > > |MUCH better introduction. Now I feel like I understand the need exactly. > | > |The "Design Considerations" section is still very confusing to me. > | > |> Though ICE specifies STUN Binding indications to be used for > |> keepalives, it requires that an agent be prepared to receive > |> connectivity check as well. If a connectivity check is received, a > |> response is generated, but there is no impact on ICE processing, as > |> described in section 10 of [RFC5245]. > | > |...so? Why is "an impact on ICE processing" necessary? > > Meant to stress these Binding request/response doesn't trigger an ICE > restart.. > > | > |> While a WebRTC browser could verify whether the peer continues to > |> send SRTCP reports before sending traffic to the peer, the usage of > |> SRTCP together with Security Descriptions [RFC4568] requires exposi= ng > |> the media keys to the JavaScript and renders SRTCP unsuitable for > |> consent freshness. > | > |Why does it "require exposing the media keys to the JavaScript"? Is this > |because of a law of nature, or is it because of the way the JavaScript > |API is being designed? Could the JS API be changed to accommodate > |SRTCP+SDES? > > That's how the API construct looks like today -- the JavaScript would get > an SDP blob from the browser containing the crypto keys used for SDES-SRT= P. > Of course, the browser could hide those keys by putting a "****" in SDP -= :). > **** > > ** ** > > ** ** > > Uh, then how would they be sent to the other side?**** > > ** ** > > As far as I can tell, with any plausible API SDES requires exposing the > keys to JS.**** > > ** ** > > -Ekr**** > > ** ** > --047d7bb03e6a41619d04e1bc38e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 17, 2013 at 8:47 PM, Muthu Arul Mozhi Perumal (mperumal= ) <mperumal@cisco.com> wrote:

|Uh, then how would they be sent to the other side?=

=A0

Ah, the browser would have to modify the SDP when it= is sent on the wire..


I don't really see how this helps since the server is going to see it a= nd call tell
the JS (remember, that's where the JS came from)= .

-Ekr

=A0

|As far as I can tell, with any plausible API SDES require= s exposing the keys to JS.

=A0

That helps..thanks.

=A0

Muthu

=A0

From: Eric Res= corla [mailto:ekr@rtfm.co= m]
Sent: Wednesday, July 17, 2013 2:32 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Simon Perreault; behave@ietf.org; rtcweb@ietf.org
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-co= nsent-freshness-04.txt

=A0

=A0

=A0

On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Pe= rumal (mperumal) <mperumal@cisco.com> wrote:

[Added rtcweb since I am not sure if everyone involv= ed there are following this discussion in behave]

Thanks for the review. See inline..

|-----Original Message-----
|From: behave-= bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Simon Perreault |Sent: Tuesday, July 16, 2013 3:05 PM
|To: behave@ietf.org
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt
|
|Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit :

|> The text and the algorithm in the draft are si= gnificantly simplified in this updated version.
|>
|> Comments welcome..
|

|MUCH better introduction. Now I feel like I underst= and the need exactly.
|
|The "Design Considerations" section is still very confusing to m= e.
|
|> =A0 =A0Though ICE specifies STUN Binding indications to be used for |> =A0 =A0keepalives, it requires that an agent be prepared to receive |> =A0 =A0connectivity check as well. =A0If a connectivity check is rece= ived, a
|> =A0 =A0response is generated, but there is no impact on ICE processin= g, as
|> =A0 =A0described in section 10 of [RFC5245].
|
|...so? Why is "an impact on ICE processing" necessary?

Meant to stress these Binding request/response doesn't trigger an ICE r= estart..

|
|> =A0 =A0While a WebRTC browser could verify whether the peer continues= to
|> =A0 =A0send SRTCP reports before sending traffic to the peer, the usa= ge of
|> =A0 =A0SRTCP together with Security Descriptions [RFC4568] requires e= xposing
|> =A0 =A0the media keys to the JavaScript and renders SRTCP unsuitable = for
|> =A0 =A0consent freshness.
|
|Why does it "require exposing the media keys to the JavaScript"?= Is this
|because of a law of nature, or is it because of the way the JavaScript
|API is being designed? Could the JS API be changed to accommodate
|SRTCP+SDES?

That's how the API construct looks like today -- the JavaScript would g= et an SDP blob from the browser containing the crypto keys used for SDES-SR= TP. Of course, the browser could hide those keys by putting a "****&qu= ot; in SDP -:).

=A0

=A0

Uh, then how would they be sent to the other side?

=A0

As far as I can tell, with any plausible API SDES re= quires exposing the keys to JS.

=A0

-Ekr

=A0


--047d7bb03e6a41619d04e1bc38e6-- From juberti@google.com Wed Jul 17 15:12:14 2013 Return-Path: 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 2A19721E804B for ; Wed, 17 Jul 2013 15:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.299, 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 UJQNbGTJ-xyd for ; Wed, 17 Jul 2013 15:12:14 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 48A7521F9FC8 for ; Wed, 17 Jul 2013 15:12:03 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so185777wid.3 for ; Wed, 17 Jul 2013 15:12:02 -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=q9hk7ezbueSHDE6DyXVKPX334cUUJEP2DDnXj8fImEk=; b=J74VEE0yXBGBdpZc9KVEuhj9jOgrQJWqY2qdIyG9SnN8HoWRpT3PdcVPAhC6ojCHzF nxd4zLAWkHI022GI5i5mdYAJKsHmUEfEzbZiMqCDUlIgVMK3QcH3AXd4cB43OBUJ/5jY P4UJXNS/flA5cKATDlZ2YHq7vUCj7T5l6HRiJ1cCMuEY2RKE3XMthyog2T6BWFg5shAJ 4EnL+8Lp/uV3PE8EbB22EG162vGx5eXuWQdV+oDCXW4ZNvoFtOFdnSBetq/FHh8BtvsU tX637dA73/eIb3dNeckN+TfZKO4eZvP9i+Qb/igAlp+93ncalbKHKkzCs5WGhmzmlm54 n8zg== 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=q9hk7ezbueSHDE6DyXVKPX334cUUJEP2DDnXj8fImEk=; b=IqSkFbFZCYjEyurIihJwDJC6440DykIcTJVTxVBa1pPFXo9+g/5ThPxmwSuw9kznJi q2nlG+v4jQvuTyFVNgyjXQUc9E8wpLuInxqVFHKTMo//Kz2Ky0PNpn7pQ74/TjR85XxX qLX5UzHCBjO9ci1mqE23KpPMpYkHyKoJVAoWmwCAxQTaEcCOqliBrhQXuJS1ymEIMK2e UFaz98i95Occ2x1TQpxelkBFWA1RVqUBLPoWMmgC7UmCt5bVf9JheWz0mnBpVs9J2rGb TPN0TxK7DmPg5CeCKvCPYkONj1seoF4q+du+bWgFogiMYzd8C+N65Atak0JAJpmmM3Ri x/Zg== X-Received: by 10.180.80.6 with SMTP id n6mr17535435wix.59.1374099122181; Wed, 17 Jul 2013 15:12:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Wed, 17 Jul 2013 15:11:42 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> From: Justin Uberti Date: Wed, 17 Jul 2013 18:11:42 -0400 Message-ID: To: Rajmohan Banavi Content-Type: multipart/alternative; boundary=14dae9cc955c1083aa04e1bc627c X-Gm-Message-State: ALoCoQk1jObkguZ1N8JoI5712KhJ9BwxD/Fbd7zjZfQ95YwUmzYlM6IJDEdlXC1EzKpK3YcJihcPx6z/EftNgnslydj+ytIwB5En187hq0MekQcB3W+NF/ppBM70Suc7HfqBeXcfibyk1YnR3jXOvnLp8FcTyjNod3J9oN+pmucklHth26UFEUlmophfmv7z6nkllj5KF182 Cc: "rtcweb@ietf.org" , behave@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:12:14 -0000 --14dae9cc955c1083aa04e1bc627c Content-Type: text/plain; charset=UTF-8 On Wed, Jul 17, 2013 at 5:09 PM, Rajmohan Banavi wrote: > Thanks for the detailed example. I agree with the entire flow you have > given. My only concern is - why should the ephemeral password be generated > by TURN server using HMAC SHA on then username string? Why can't this be > some random unique string? > > Taking your example - > > Suppose TURN server generates credentials, username = > "12334939:mbzrxpgjys" and password ="+somerandomstring+". This is a > randomly generated string and passed onto webrtc app. The TURN server also > stores these credentials for later validation. > var iceServer = { > "username": 12334939:mbzrxpgjys, > "credential": +somerandomstring+, > }; > > These credentials are passed from JS to the webrtc client stack in the > browser. > > On Browser WebTRC Client. > key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+) > Similarly on the TURN server, the key for MESSAGE-INTEGRITY is calculated > using > key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+) > > So the browser and turn server use the same input to the M-I. The one > implementation related advantage I see with this way of generation of TURN > password using HMAC is that the TURN server need not really store the HMAC > generated password, but can calculate the same using the USERNAME attribute > in the received TURN request. > Correct, but that is a significant advantage, especially when the web and TURN servers are separate entities. > > In fact, I do not see why the sharedsecret needs to be shared between the > TURN server and the WebRTC application. The sharedsecret key "secret" is > only required by the TURN server for validating the received TURN ALLOCATE > requests once it has generated and sent out the ephemeral credentials. What > does the WebRTC application do with the shared secret key? > The WebRTC client application doesn't see the secret key, this is only shared between the web and TURN servers. > > On Thu, Jul 18, 2013 at 2:09 AM, Philipp Hancke > wrote: > >> Am 17.07.2013 20:56, schrieb Rajmohan Banavi: >> >> Hi Justin, >>> >>> I reviewed draft-uberti-behave-turn-rest-**00 and have the following >>> comments. >>> >> [...] >> >>> 2. Sec 4.3 last paragraph - "Because the password is derived from the >>> >>> USERNAME, successful verification of the MESSAGE-INTEGRITY ensures >>> that the >>> username is trustworthy". I believe this validation is taken care of >>> in the >>> TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN >>> client generates a long term key which is computed as => key = >>> MD5(username ":" realm ":" SASLprep(password)). This key is used to >>> perform >>> hmac on the message. The same is done on the TURN server end as >>> well. If >>> the MESSAGE-INTEGRITY is verified, then it implies that the username >>> is >>> trustworthy. >>> >> >> Let me try to address that with a lenghty example: >> The web server returns >> password = BASE64(HMAC-SHA1(username, sharedsecret)) >> to the browser. >> >> For example, with username = "12334939:mbzrxpgjys" and sharedsecret >> "secret", the password given to the browser would be >> "+4pCXR06gx/cqAikLYnBajtZW6E=" (hopefully) >> >> >> >> >> The browser passes the username, uri and password to it's webrtc stack. >> The password is exposed to the user of the browser (which might be anyone >> surfing your website) during that process. >> >> That stack does long term authentication and uses this password string as >> input for calculating MESSAGE-INTEGRITY with >> key = MD5(username ":" realm ":" SASLprep(password)) >> >> For the example this would be >> key =MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/** >> cqAikLYnBajtZW6E=") >> >> >> >> >> On the TURN server, the key for MESSAGE-INTEGRITY is calculated using >> key = MD5(username ":" realm ":" SASLprep(BASE64(HMAC-SHA1(**USERNAME, >> sharedsecret)) >> >> So for the example this would be >> = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep(BASE64(HMAC-SHA1("**12334939:mbzrxpgjys", >> "secret")) >> = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/** >> cqAikLYnBajtZW6E=") >> >> So the browser and turn server use the same input to the M-I. This can be >> done by looking at the request alone given the shared secret. >> >> >> Does that make it clearer? >> >> philipp, >> who only understood it after implementing it >> > > > > -- > > Life is here and now, not yesterday, not tomorrow...! > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --14dae9cc955c1083aa04e1bc627c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 17, 2013 at 5:09 PM, Rajmohan Banavi = <rajmohanb= anavi@gmail.com> wrote:
Thanks for the detailed exa= mple. I agree with the entire flow you have given. My only concern is - why= should the ephemeral password be generated by TURN server using HMAC SHA o= n then username string? Why can't this be some random unique string?
Taking your example -=C2=A0

Suppose TURN server ge= nerates credentials, username =3D "12334939:mbzrxpgjys" and passw= ord =3D&= quot;+somerandomstring+". This is a randomly generated string and pass= ed onto webrtc app. The TURN server also stores these credentials for later= validation.
var iceServer =3D {
= =C2=A0 =C2=A0 =C2=A0"username":= =C2=A012= 334939:mbzrxpgjys,
=C2=A0 =C2=A0 =C2=A0"credential&= quot;:=C2=A0+somerandomstring+,
=C2=A0 =C2=A0};

These credentials are passed from JS to the webrtc clien= t stack in the browser.

On Brows= er WebTRC Client.=C2=A0
key =3D MD5(12334939:mbzrxpgjys=C2=A0":" realm ":&= quot;=C2=A0+somerandomstring+)
Similarly = on the TURN server, the key for MESSAGE-INTEGRITY is calculated using
key =3D MD5(12334939:mbzrxpgjys= =C2=A0":&q= uot; realm ":"=C2=A0+somerandomstring+)

So the browser and turn server u= se the same input to the M-I. The one implementation related advantage I se= e with this way of generation of TURN password using HMAC is that the TURN = server need not really store the HMAC generated password, but can calculate= the same using the USERNAME attribute in the received TURN request.=

Correct, but that is a significant a= dvantage, especially when the web and TURN servers are separate entities.= =C2=A0

In = fact, I do not see why the sharedsecret needs to be shared between the TURN= server and the WebRTC application. The sharedsecret key "secret"= is only required by the TURN server for validating the received TURN ALLOC= ATE requests once it has generated and sent out the ephemeral credentials. = What does the WebRTC application do with the shared secret key?

The WebRTC client application doesn&= #39;t see the secret key, this is only shared between the web and TURN serv= ers.
=C2=A0

On Thu, Jul 18, 2013 at 2:09 AM, Ph= ilipp Hancke <fippo@goodadvice.pages.de> wrote:
Am 17.07.2013 20:56, schrieb Rajmohan Banavi= :

Hi Justin,

I reviewed draft-uberti-behave-turn-rest-00 and have the following c= omments.
[...]
=C2=A0 =C2=A0 2. Sec 4.3 last paragraph - "Because the password is der= ived from the

=C2=A0 =C2=A0 USERNAME, successful verification of the MESSAGE-INTEGRITY en= sures that the
=C2=A0 =C2=A0 username is trustworthy". I believe this validation is t= aken care of in the
=C2=A0 =C2=A0 TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, = the TURN
=C2=A0 =C2=A0 client generates a long term key which is computed as =3D>= key =3D
=C2=A0 =C2=A0 MD5(username ":" realm ":" SASLprep(passw= ord)). This key is used to perform
=C2=A0 =C2=A0 hmac on the message. The same is done on the TURN server end = as well. If
=C2=A0 =C2=A0 the MESSAGE-INTEGRITY is verified, then it implies that the u= sername is
=C2=A0 =C2=A0 trustworthy.

Let me try to address that with a lenghty example:
The web server returns
password =3D BASE64(HMAC-SHA1(username, sharedsecret))
to the browser.

For example, with username =3D "12334939:mbzrxpgjys" and sharedse= cret "secret", the password given to the browser would be
"+4pCXR06gx/cqAikLYnBajtZW6E=3D" (hopefully)




The browser passes the username, uri and password to it's webrtc stack.=
The password is exposed to the user of the browser (which might be anyone s= urfing your website) during that process.

That stack does long term authentication and uses this password string as i= nput for calculating MESSAGE-INTEGRITY with
key =3D MD5(username ":" realm ":" SASLprep(password))<= br>
For the example this would be
key =3DMD5("12334939:mbzrxpgjys" ":" realm ":"= ; SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=3D")




On the TURN server, the key for MESSAGE-INTEGRITY is calculated using
key =3D MD5(username ":" realm ":" SASLprep(BASE64(HMAC= -SHA1(USERNAME, sharedsecret))

So for the example this would be
=C2=A0=3D MD5("12334939:mbzrxpgjys" ":" realm ":&q= uot; SASLprep(BASE64(HMAC-SHA1("12334939:mbzrxpgjys", &quo= t;secret"))
=C2=A0=3D MD5("12334939:mbzrxpgjys" ":" realm ":&q= uot; SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=3D")

So the browser and turn server use the same input to the M-I. This can be d= one by looking at the request alone given the shared secret.


Does that make it clearer?

philipp,
who only understood it after implementing it



--

Life is here and now, not yesterday, not tomorrow...!

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


--14dae9cc955c1083aa04e1bc627c-- From ted.ietf@gmail.com Wed Jul 17 15:40:38 2013 Return-Path: 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 5A1DA21F9C28 for ; Wed, 17 Jul 2013 15:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, 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 tpK0a3bCM8jy for ; Wed, 17 Jul 2013 15:40:37 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1229421F9D4F for ; Wed, 17 Jul 2013 15:40:36 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so5229818iec.8 for ; Wed, 17 Jul 2013 15:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gv4nBqgcBEezlSwEzpLcyLS98CJAEARUozL3m3Hq2zU=; b=FlkZxeUnUbGgQzt/y95vaLfh3L/iqTAz1tiH4YEj7vt+xZXbpi+b8yAkyL0PgeXbpq h/swh0G8lJES5wyWhMPPH8fiOn0eNvLnAEUF7uVPC0kvCgNAIc2ceNI9cCV55iGk5Qep WObfYECnrZ6BqVT7+Oe/KBD7+FV7TgnmsxNe7ftTFfohrLeTBTLEvNtzaVHxiRwj/33K 2x/x+Z70zE9sdTP8SjI/qhfDGk9Q1ngE6rQJTqh8PMYgJfgtfk6lVYU8ptn3ZV0CIe0t SmaNzDutUolbcDWre7ISgUmUhwHnMhvJsrC/uL06Gf9iwOLVw9+Dk6tLyQ3cNzBcAotX mpLA== MIME-Version: 1.0 X-Received: by 10.43.67.73 with SMTP id xt9mr5476719icb.99.1374100836377; Wed, 17 Jul 2013 15:40:36 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Wed, 17 Jul 2013 15:40:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 15:40:36 -0700 Message-ID: From: Ted Hardie To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=089e015370963e3d4a04e1bcc86a Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:40:38 -0000 --089e015370963e3d4a04e1bcc86a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 17, 2013 at 2:29 PM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > > I am frankly quite concerned given earlier comments that yes, the W3C had > given responsibility for "JSEP" and the resulting SDP work to IETF, and so > now we have the IETF WG making decisions but the discussion happening on > the W3C list -- which means there's no "paper trail" prior to the IETF > meeting on an IETF list about how the participants have weighed in -- and > then conversely when the W3C spec gets to last call there will be no "paper > trail" at the W3C showing how decisions had been reached about the SDP > "API", as that happened over in the MMUSIC WG, which list was not even > copied on this message. > > All three lists you cited have public archives, so it is clearly not the case that there is no "paper trail". But it does occasionally get confusing, and the chairs made the "locus of API discussions" point in order to take a particular set of discussions proposing a significant change to the API and reduce the number of places someone who have to follow to contribute to that discussion. I grieve that this has disappointed you, Ted --089e015370963e3d4a04e1bcc86a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 2:29 PM, Matthew Kaufman (SKYPE) = <matthew.= kaufman@skype.net> wrote:
=A0
I am frankly quite concerned given earlier comments that yes, the W3C had g= iven responsibility for "JSEP" and the resulting SDP work to IETF= , and so now we have the IETF WG making decisions but the discussion happen= ing on the W3C list -- which means there's no "paper trail" p= rior to the IETF meeting on an IETF list about how the participants have we= ighed in -- and then conversely when the W3C spec gets to last call there w= ill be no "paper trail" at the W3C showing how decisions had been= reached about the SDP "API", as that happened over in the MMUSIC= WG, which list was not even copied on this message.

=A0
All three lists you cited have public archives, so it is cle= arly not the case that there is no "paper trail".=A0=A0 But it do= es occasionally get confusing, and the chairs made the "locus of API d= iscussions" point in order to take a particular set of discussions pro= posing a significant change to the API and reduce the number of places some= one who have to follow to contribute to that discussion.=A0

I grieve that this has disappointed you,

Ted
--089e015370963e3d4a04e1bcc86a-- From ted.ietf@gmail.com Wed Jul 17 16:05:14 2013 Return-Path: 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 628E321F8925 for ; Wed, 17 Jul 2013 16:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, 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 Nqk0LCms5Mg0 for ; Wed, 17 Jul 2013 16:05:14 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id DCC5821E8083 for ; Wed, 17 Jul 2013 16:05:13 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so5610550ied.0 for ; Wed, 17 Jul 2013 16:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RdiqVG282R+yT9hV+Qe57MGhWtpRp0EqFprp52Ps7hg=; b=sSVbBzUzCYjOckaFWV4l7jBEkQtgvDdJVob6nVl3OWe2oWuZoj45erTFzooPyMNeJK 6KkFDSvhw3rFmVBN4iMsYJeG+WNgZt49C7ZYhGSUy1qgEO3J0Gbl/Aer123S4775+gXe 1zwn4VIqEgDjLzSBpXsbYm1OdfMHqMWDSMLSxca1eh7oVwpGTxCsMFgZCYSLz3IfMojD hdZmUluoYaG8Xsabs6enSkOAK3NOrsSnZQGrospqC0zG2nWyAuIu8L0icI8zwgmJRbDt nO+Cy04Hq6NOWIWrdU2JGeCs+bceg9AK982I1jiLJRNX5yBBoicxkElHLxQIWIU65HVs bBEw== MIME-Version: 1.0 X-Received: by 10.50.66.210 with SMTP id h18mr11399546igt.19.1374102313419; Wed, 17 Jul 2013 16:05:13 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Wed, 17 Jul 2013 16:05:13 -0700 (PDT) Date: Wed, 17 Jul 2013 16:05:13 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7bdca46846cbe004e1bd206e Subject: [rtcweb] (possibly very) draft agenda uploaded X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 23:05:14 -0000 --047d7bdca46846cbe004e1bd206e Content-Type: text/plain; charset=ISO-8859-1 Today is the required date for uploading an agenda for the working group and I have done so here: http://www.ietf.org/proceedings/87/agenda/agenda-87-rtcweb There is still ongoing discussion and further agenda bashing is possible, so please continue to provide feedback. We are confident that we will discuss SDES, the results of the MMUSIC plan discussions from earlier in the week, and the data channel documents. Placement in the agenda and time of those three may still shift, though, so please plan on attending both days if there are topics where you want to be in the face to face discussion. thanks, Ted Hardie --047d7bdca46846cbe004e1bd206e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Today is the required date for uploading an agenda for the working group an= d I have done so here:

http://www.ietf.org/proceedings/87/agenda/agenda-= 87-rtcweb

There is still ongoing discussion and further agenda bashing is possibl= e, so please continue to provide feedback.
We are confident that we will= discuss SDES, the results of the MMUSIC plan discussions from earlier
in the week, and the data channel documents.=A0 Placement in the agenda and= time of those three may
still shift, though, so please plan on attendin= g both days if there are topics where you want to be in
the face to face= discussion.

thanks,

Ted Hardie


--047d7bdca46846cbe004e1bd206e-- From fineberg@vline.me Wed Jul 17 17:09:54 2013 Return-Path: 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 CB51B21F9ED8 for ; Wed, 17 Jul 2013 17:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 wU47T5B1Us4I for ; Wed, 17 Jul 2013 17:09:50 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 24C7321F9D45 for ; Wed, 17 Jul 2013 17:09:50 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so3013575obc.40 for ; Wed, 17 Jul 2013 17:09:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=ARXkYoB1EOSVygnDH0O6WqCleS3XxOwchU5Gm2dCRTs=; b=fOTwuiADsK8hS14EB1GCyn5brX525gHjX1iIA5vZYNjEns9qt4fMRbnzztMSJvQh6d PN+FdIWLVjkvxXekklpjkJuSLOB3vRSPcjSBsNKRGs5ZmELXpDDx3iZG/0fL2BrgnhSn ksENFzaHfcQNg87tPS+9/HzAv3hrn2XyIxHY/213iBtpYA2Q0F6rRwrCe99ML1tE/lR0 +oAKfkcLkHMzMJAHHSXXogl7CGfRp17VII+NJzGa1ESMr3vDB+pZ4eS7rl874n2wvbSG wYl68mPsbScXbbQq6nSHS0auZ7hLkO2ShRyncxxN70vFmY7yNqjk11xB7XH4OhC2UT+u v+sw== X-Received: by 10.60.39.193 with SMTP id r1mr10908554oek.40.1374106189589; Wed, 17 Jul 2013 17:09:49 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id tv3sm11065184obb.8.2013.07.17.17.09.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 17:09:48 -0700 (PDT) Message-ID: <51E7324A.3090405@vline.me> Date: Wed, 17 Jul 2013 17:09:46 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="------------030403020500010002050000" X-Gm-Message-State: ALoCoQkky/GqCeHI27lVEaNnUPQvW8I8BQ/fQ76v8CC+3CZidZNxw+n0JNXAI5uZyoHWih4aQyXE Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 00:09:55 -0000 This is a multi-part message in MIME format. --------------030403020500010002050000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. --------------030403020500010002050000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.
--------------030403020500010002050000-- From bernard_aboba@hotmail.com Wed Jul 17 20:27:05 2013 Return-Path: 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 9671A21F9A05 for ; Wed, 17 Jul 2013 20:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 IGCL-Cd28uNr for ; Wed, 17 Jul 2013 20:27:01 -0700 (PDT) Received: from blu0-omc4-s6.blu0.hotmail.com (blu0-omc4-s6.blu0.hotmail.com [65.55.111.145]) by ietfa.amsl.com (Postfix) with ESMTP id BFA1E21F92C2 for ; Wed, 17 Jul 2013 20:27:00 -0700 (PDT) Received: from BLU169-W123 ([65.55.111.136]) by blu0-omc4-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Jul 2013 20:26:58 -0700 X-TMN: [6DYaeqNBSyq1ZK6x/N6CromwRGRfgS8a] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_4899aed9-d0eb-4689-81a9-9545eb48347c_" From: Bernard Aboba To: Adam Fineberg , "rtcweb@ietf.org" Date: Wed, 17 Jul 2013 20:26:58 -0700 Importance: Normal In-Reply-To: <51E7324A.3090405@vline.me> References: <51E7324A.3090405@vline.me> MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2013 03:26:58.0869 (UTC) FILETIME=[A92F8650:01CE8366] Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 03:27:05 -0000 --_4899aed9-d0eb-4689-81a9-9545eb48347c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Since the need is not codec specific (e.g. it arises with any codec support= ing temporal=2C spatial and quality scalability)=2C why=20 a VP8-specific RTP extension?=20 =20 Date: Wed=2C 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt =0A= =0A= =0A= =0A= =0A= =0A= Hi=2C=0A= =0A= I'm working on=0A= WebRTC services and have found that while developing services that=0A= forward VP8 video streams if we want to take advantage of the VP8=0A= temporal scaling we must get the temporal layer information from=0A= the RTP header which requires us to decrypt the SRTP packets. This=0A= is undesirable both because the middle-box needs to have access to=0A= the keys as well as the because of the added overhead of the=0A= decrypt/encrypt cycle. This draft proposes an RTP header extension=0A= that will allow us to use the VP8 temporal layer information=0A= included in the header extension and therefore do forwarding=0A= without SRTP decryption. Comments welcome.=0A= =0A= Regards=2C=0A= Adam Fineberg=0A= fineberg at vline.com =0A= =20 =0A= -------- Original Message --------=0A= =0A= =0A= =0A= Subject:=0A= New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt=0A= =0A= =0A= Date:=0A= Tue=2C 09 Jul 2013 10:02:05 -0700=0A= =0A= =0A= From:=0A= internet-drafts=0A= =0A= at ietf.org=0A= =0A= =0A= To:=0A= Adam Fineberg =0A= =0A= =0A= =0A= =20 =0A= =20 =0A= A new version of I-D=2C draft-fineberg-avtext-temporal-layer-ext-00.t= xt=0A= has been successfully submitted by Adam Fineberg and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-fineberg-avtext-temporal-layer-ext=0A= Revision: 00=0A= Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp= oral Layer Information=0A= Creation date: 2013-07-08=0A= Group: Individual Submission=0A= Number of pages: 6=0A= URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt=0A= Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext=0A= Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00=0A= =0A= =0A= Abstract:=0A= This document defines a mechanism by which packets of Real-Time=0A= Tranport Protocol (RTP) video streams encoded with the VP8 codec can=0A= indicate=2C in an RTP header extension=2C the temporal layer information= =0A= about the frame encoded in the RTP packet. This information can be=0A= used in a middlebox performing bandwidth management of streams=0A= without requiring it to decrypt the streams.=0A= =0A= =0A= =0A= =0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb = --_4899aed9-d0eb-4689-81a9-9545eb48347c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Since the need is not codec spec= ific (e.g. it arises with any codec supporting temporal=2C spatial and qual= ity scalability)=2C why
 =3Ba VP8-specific RTP extension?
 = =3B
Date: Wed=2C 17 Jul 2013 17:09:46 -0700=
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd= : New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.= txt

=0A= =0A= =0A= =0A= =0A= =0A= Hi=2C
=0A=
=0A= I'm working on=0A= WebRTC services and have found that while developing services that=0A= forward VP8 video streams if we want to take advantage of the VP8=0A= temporal scaling we must get the temporal layer information from=0A= the RTP header which requires us to decrypt the SRTP packets. This=0A= is undesirable both because the middle-box needs to have access to=0A= the keys as well as the because of the added overhead of the=0A= decrypt/encrypt cycle. This draft proposes an RTP header extension=0A= that will allow us to use the VP8 temporal layer information=0A= included in the header extension and therefore do forwarding=0A= without SRTP decryption. Comments welcome.
=0A=
=0A= Regards=2C
=0A= Adam Fineberg
=0A=
fineberg at vline.com
=0A=
=0A= -------- Original Message --------=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
Subje= ct:New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt
Date:= Tue=2C 09 Jul 2013 10:02:05 -0700
From:= internet-drafts=0A= =0A= at ietf.org
To:=0A= Adam Fineberg = =3B<=3Bfineberg at=0A= vline.com>=3B
=0A=
=0A=
=0A= 
A new version of I-D=2C draft-fineberg-avtext-temporal-l=
ayer-ext-00.txt=0A=
has been successfully submitted by Adam Fineberg and posted to the=0A=
IETF repository.=0A=
=0A=
Filename:	 draft-fineberg-avtext-temporal-layer-ext=0A=
Revision:	 00=0A=
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information=0A=
Creation date:	 2013-07-08=0A=
Group:		 Individual Submission=0A=
Number of pages: 6=0A=
URL:             http://www.ietf.org/internet-drafts/draft-=
fineberg-avtext-temporal-layer-ext-00.txt=0A=
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext=
-temporal-layer-ext=0A=
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-tempor=
al-layer-ext-00=0A=
=0A=
=0A=
Abstract:=0A=
   This document defines a mechanism by which packets of Real-Time=0A=
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can=0A=
   indicate=2C in an RTP header extension=2C the temporal layer information=
=0A=
   about the frame encoded in the RTP packet.  This information can be=0A=
   used in a middlebox performing bandwidth management of streams=0A=
   without requiring it to decrypt the streams.=0A=
=0A=
=0A= =0A= =0A=
_______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb
= --_4899aed9-d0eb-4689-81a9-9545eb48347c_-- From harald@alvestrand.no Wed Jul 17 21:47:49 2013 Return-Path: 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 BD5CE21F86B1 for ; Wed, 17 Jul 2013 21:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 eF80k586Zhnp for ; Wed, 17 Jul 2013 21:47:43 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 33E1821F84A1 for ; Wed, 17 Jul 2013 21:47:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D290339E15B for ; Thu, 18 Jul 2013 06:47:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOLHmNRK+EOd for ; Thu, 18 Jul 2013 06:47:30 +0200 (CEST) Received: from [172.30.42.116] (c-58f0e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.240.88]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 79DF639E0FA for ; Thu, 18 Jul 2013 06:47:30 +0200 (CEST) Message-ID: <51E77362.7070801@alvestrand.no> Date: Thu, 18 Jul 2013 06:47:30 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: [rtcweb] e= lines (Re: Summary of Application Developers' opinions ..) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 04:47:49 -0000 Matthew, thanks for sending 12 messages in 3 hours to the mailing list. Just one point on which I corrected you before, but since I see you're repeating it: On 07/17/2013 11:58 PM, Matthew Kaufman (SKYPE) wrote: > - What if someone adds an r= or p= or e=? The code for handling an e= line has been in Chrome since a very early release. You claimed in Lyon that you'd tested it and failed to have it parse, but I never saw the test case; you may have inserted it into the wrong place, rendering the SDP invalid. The SDP specification is quite strict about the order of these fields, exactly to make it simpler to write parsers. From harald@alvestrand.no Thu Jul 18 01:17:06 2013 Return-Path: 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 C297A21E8085 for ; Thu, 18 Jul 2013 01:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 FTRyYdIyS7SS for ; Thu, 18 Jul 2013 01:17:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5364621E808D for ; Thu, 18 Jul 2013 01:16:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DDD2C39E235; Thu, 18 Jul 2013 10:16:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REtV+tUDyUO5; Thu, 18 Jul 2013 10:16:50 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9964A39E0D7; Thu, 18 Jul 2013 10:16:50 +0200 (CEST) Message-ID: <51E7A472.3010206@alvestrand.no> Date: Thu, 18 Jul 2013 10:16:50 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org, Adam Fineberg References: <51E7324A.3090405@vline.me> In-Reply-To: <51E7324A.3090405@vline.me> Content-Type: multipart/alternative; boundary="------------020803000601070607080907" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 08:17:06 -0000 This is a multi-part message in MIME format. --------------020803000601070607080907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/18/2013 02:09 AM, Adam Fineberg wrote: > Hi, > > I'm working on WebRTC services and have found that while developing > services that forward VP8 video streams if we want to take advantage > of the VP8 temporal scaling we must get the temporal layer information > from the RTP header which requires us to decrypt the SRTP packets. > This is undesirable both because the middle-box needs to have access > to the keys as well as the because of the added overhead of the > decrypt/encrypt cycle. This draft proposes an RTP header extension > that will allow us to use the VP8 temporal layer information included > in the header extension and therefore do forwarding without SRTP > decryption. Comments welcome. Just checking - you named your draft with the -avtext- convention; this means that you want comments to go to avtext, yes? > > Regards, > Adam Fineberg > fineberg at vline.com > > -------- Original Message -------- > Subject: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > Date: Tue, 09 Jul 2013 10:02:05 -0700 > From: internet-drafts at ietf.org > To: Adam Fineberg > > > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > has been successfully submitted by Adam Fineberg and posted to the > IETF repository. > > Filename: draft-fineberg-avtext-temporal-layer-ext > Revision: 00 > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > Abstract: > This document defines a mechanism by which packets of Real-Time > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > indicate, in an RTP header extension, the temporal layer information > about the frame encoded in the RTP packet. This information can be > used in a middlebox performing bandwidth management of streams > without requiring it to decrypt the streams. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020803000601070607080907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/18/2013 02:09 AM, Adam Fineberg wrote:
Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Just checking - you named your draft with the -avtext- convention; this means that you want comments to go to avtext, yes?



Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.



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

--------------020803000601070607080907-- From harald@alvestrand.no Thu Jul 18 01:23:56 2013 Return-Path: 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 730CB21F8417 for ; Thu, 18 Jul 2013 01:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 CypMZt+5zroQ for ; Thu, 18 Jul 2013 01:23:45 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0F41821F8FF3 for ; Thu, 18 Jul 2013 01:23:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2012A39E0FA for ; Thu, 18 Jul 2013 10:23:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD9xot+UmWmg for ; Thu, 18 Jul 2013 10:23:08 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7961E39E0D7 for ; Thu, 18 Jul 2013 10:23:08 +0200 (CEST) Message-ID: <51E7A5EC.9000305@alvestrand.no> Date: Thu, 18 Jul 2013 10:23:08 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E77362.7070801@alvestrand.no> In-Reply-To: <51E77362.7070801@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] e= lines (Re: Summary of Application Developers' opinions ..) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 08:23:56 -0000 Since Matthew was taking about API, this belongs on public-webrtc, not rtcweb. Please ignore. Harald On 07/18/2013 06:47 AM, Harald Alvestrand wrote: > Matthew, thanks for sending 12 messages in 3 hours to the mailing list. > > Just one point on which I corrected you before, but since I see you're > repeating it: > > On 07/17/2013 11:58 PM, Matthew Kaufman (SKYPE) wrote: >> - What if someone adds an r= or p= or e=? > The code for handling an e= line has been in Chrome since a very early > release. > You claimed in Lyon that you'd tested it and failed to have it parse, > but I never saw the test case; you may have inserted it into the wrong > place, rendering the SDP invalid. > > The SDP specification is quite strict about the order of these fields, > exactly to make it simpler to write parsers. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Michael.Tuexen@lurchi.franken.de Thu Jul 18 02:03:59 2013 Return-Path: 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 4130F21E809A for ; Thu, 18 Jul 2013 02:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 btqdmp0FaREA for ; Thu, 18 Jul 2013 02:03:58 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 4D59C21E8098 for ; Thu, 18 Jul 2013 02:03:58 -0700 (PDT) Received: from [192.168.1.200] (p508F0EA8.dip0.t-ipconnect.de [80.143.14.168]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CC0751C0C0693; Thu, 18 Jul 2013 11:03:55 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Thu, 18 Jul 2013 11:03:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <391CDA9E-7EE3-4909-83CC-5B38A9BED219@lurchi.franken.de> References: <20130715192354.17142.94001.idtracker@ietfa.amsl.com> To: Peter Thatcher X-Mailer: Apple Mail (2.1508) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 09:03:59 -0000 On Jul 16, 2013, at 2:43 AM, Peter Thatcher = wrote: > Hey Randell, can you give a short summary of the changes, if any, that = I would or other implementors would need to know about? Hi Peter, the changes don't require any code change. The changes are a consequence = of moving the RTCWeb specific things from http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-01 to http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-05 There is no technical change involved. Best regards Michael >=20 >=20 > On Mon, Jul 15, 2013 at 12:23 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : RTCWeb Data Channels > Author(s) : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-channel-05.txt > Pages : 13 > Date : 2013-07-15 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) working group is charged = to > provide protocol support for direct interactive rich communication > using audio, video, and data between two peers' web-browsers. This > document specifies the non-media data transport aspects of the = WebRTC > framework. It provides an architectural overview of how the Stream > Control Transmission Protocol (SCTP) is used in the WebRTC context = as > a generic transport service allowing Web Browser to exchange = generic > data from peer to peer. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-data-channel-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From Michael.Tuexen@lurchi.franken.de Thu Jul 18 02:11:55 2013 Return-Path: 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 EF5F621E80AA for ; Thu, 18 Jul 2013 02:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Y3UqSnXRrEHw for ; Thu, 18 Jul 2013 02:11:55 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 589AF21E809B for ; Thu, 18 Jul 2013 02:11:55 -0700 (PDT) Received: from [192.168.1.200] (p508F0EA8.dip0.t-ipconnect.de [80.143.14.168]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 557071C0C0692; Thu, 18 Jul 2013 11:11:54 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Thu, 18 Jul 2013 11:11:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130715203130.5677.31855.idtracker@ietfa.amsl.com> To: Peter Thatcher X-Mailer: Apple Mail (2.1508) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 09:11:56 -0000 On Jul 16, 2013, at 2:43 AM, Peter Thatcher = wrote: > Hey Randell, can you give a short summary of the changes, if any, that = I would or other implementors would need to know about? Hi Peter, using = http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-jesup-= rtcweb-data-protocol-04.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-rtc= web-data-protocol-00.txt you see that in addition to clarifications and cleanups * external negotiation of data channels is described * the packet format of the DATA_CHANNEL_OPEN message as been changed Both of these changes require code changes. Best regards Michael >=20 >=20 > On Mon, Jul 15, 2013 at 1:31 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : WebRTC Data Channel Protocol > Author(s) : Randell Jesup > Salvatore Loreto > Michael Tuexen > Filename : draft-ietf-rtcweb-data-protocol-00.txt > Pages : 11 > Date : 2013-07-15 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) working group is charged = to > provide protocols to support for direct interactive rich > communication using audio, video, and data between two peers' web- > browsers. This document specifies an actual (minor) protocol for = how > the JS-layer DataChannel objects provide the data channels between > the peers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ranjit.avasarala@nsn.com Thu Jul 18 02:21:49 2013 Return-Path: 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 E696411E80D5 for ; Thu, 18 Jul 2013 02:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 6qr-SlnKBoB3 for ; Thu, 18 Jul 2013 02:21:44 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A4F0521E809B for ; Thu, 18 Jul 2013 02:21:32 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6I9LShD006151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jul 2013 11:21:29 +0200 Received: from SGSIHTC003.nsn-intra.net ([10.159.225.20]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6I9LJCj021159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 11:21:27 +0200 Received: from SGSIHTC008.nsn-intra.net (10.159.225.25) by SGSIHTC003.nsn-intra.net (10.159.225.20) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 17:20:37 +0800 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.242]) by SGSIHTC008.nsn-intra.net ([10.159.225.25]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 17:20:37 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: "ext Muthu Arul Mozhi Perumal (mperumal)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoCAAAceUIAAG3TAgAAKkwCAAFNjgIABRHCQ Date: Thu, 18 Jul 2013 09:20:37 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10288 X-purgate-ID: 151667::1374139289-000017BA-BA6CF418/0-0/0-0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 09:21:49 -0000 One more question - Would consent freshness be an additional feature as par= t of ICE functionality? Regards Ranjit -----Original Message----- From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Sent: Wednesday, July 17, 2013 7:48 PM To: Avasarala, Ranjit (NSN - IN/Bangalore) Cc: rtcweb@ietf.org Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-f= reshness-04.txt |-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.= com] |Sent: Wednesday, July 17, 2013 2:36 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |My comments inline | |Regards |Ranjit | |-----Original Message----- |From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |Sent: Wednesday, July 17, 2013 2:16 PM |To: Avasarala, Ranjit (NSN - IN/Bangalore) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | ||If many public STUN servers and call servers that implement STUN or ICEli= te ||functionalities, are not expected to support | |I should have said they have no role to play. It is similar to peer-to-pee= r ICE connectivity checks -- |those checks don't go through public STUN or call servers at all. |[Ranjit] But there can be scenarios where RTCWebBrowsers do talk to WebRTC= Gateways which could be co- |located with call handling servers. Then it won't make sense to have this = feature. An RTCWeb gateway wouldn't have to do anything fancier than what it already= does for ICE connectivity checks.=20 | |The difference between ICE connectivity checks and consent freshness check= s is that the former is |performed before session establishment and the later is performed after se= ssion establishment. |[Ranjit] Why do you need to check consent of the peer after session is est= ablished? Ideally I should |check consent before session establishment. If the peer does not want to r= eceive traffic, then session |itself should not be established. See draft-ietf-rtcweb-security-arch: 4.4. Communications and Consent Freshness From a security perspective, everything from here on in is a little anticlimactic: Alice and Bob exchange data protected by the keys negotiated by DTLS. Because of the security guarantees discussed in the previous sections, they know that the communications are encrypted and authenticated. The one remaining security property we need to establish is "consent freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline. ICE specifies periodic STUN keepalizes but only if media is not flowing. Because the consent issue is more difficult here, we require RTCWeb implementations to periodically send keepalives. As described in Section 5.3, these keepalives MUST be based on the consent freshness mechanism specified in [I-D.muthu-behave-consent-freshness]. If a keepalive fails and no new ICE channels can be established, then the session is terminated. | ||then who would have interest to support this functionality? | |RTCWEB browsers and browser-like platforms. |[Ranjit] browser may implement, but it would be very customized one. I do = not think the intermediate |entities would want to support. You seem to be completely missing the very purpose of consent. | ||Ideally getting consent for receiving traffic or call should be part of s= ignaling. ||I do not think using STUN is appropriate. | |ICE already does that. You think it is inappropriate? |[Ranjit] I am saying that using STUN for consent check is not appropriate = as STUN has other dedicated |functionality to do - like connectivity checks, keep alives, etc.=20 See draft-ietf-rtcweb-security and draft-ietf-rtcweb-security. |Also in cases of Symmetric NATs where STUN fails, TURN is needed. Then the= proposed feature would anyway fail. The solution is built on top of ICE, so should work across these. Muthu | |Muthu | ||-----Original Message----- ||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn= .com] ||Sent: Wednesday, July 17, 2013 12:16 PM ||To: Muthu Arul Mozhi Perumal (mperumal) ||Cc: rtcweb@ietf.org ||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||Hi Muthu || ||If many public STUN servers and call servers that implement STUN or ICEli= te functionalities, are not ||expected to support, then who would have interest to support this functio= nality? Ideally getting ||consent for receiving traffic or call should be part of signaling. I do n= ot think using STUN is ||appropriate. || ||Regards ||Ranjit || || || || ||-----Original Message----- ||From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] ||Sent: Wednesday, July 17, 2013 12:07 PM ||To: Avasarala, Ranjit (NSN - IN/Bangalore) ||Cc: rtcweb@ietf.org; behave@ietf.org ||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||Ranjit, || |||Many publicly available STUN servers or those that are part of Call serv= ers |||may not support this. || ||Public STUN servers and call servers are not expected to support this. || |||Can't there be some other neutral mechanism to query peer's consent - th= rough |||signaling? || ||No. That signaling between the JS and the web server could be anything (S= IP or XMPP or proprietary or ||whatever) and the browser has no control over it. || ||Muthu || |||-----Original Message----- |||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@ns= n.com] |||Sent: Wednesday, July 17, 2013 11:19 AM |||To: Muthu Arul Mozhi Perumal (mperumal) |||Cc: rtcweb@ietf.org; behave@ietf.org |||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consen= t-freshness-04.txt ||| |||Hi Muthu ||| |||Though using STUN request/response may be good for querying about consen= t, I feel it is overloading |||the functionality of STUN. Many publicly available STUN servers or those= that are part of Call ||servers |||may not support this. ||| |||Can't there be some other neutral mechanism to query peer's consent - th= rough signaling? ||| ||| |||Regards |||Ranjit ||| ||| ||| |||-----Original Message----- |||From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf= Of ext Simon Perreault |||Sent: Tuesday, July 16, 2013 6:34 PM |||To: Muthu Arul Mozhi Perumal (mperumal) |||Cc: rtcweb@ietf.org; behave@ietf.org |||Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consen= t-freshness-04.txt ||| |||Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |||> |> |> Liveness timer: If no packets have been received on the local= port in |||> |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript tha= t |||> |> |> connectivity has been lost. The JavaScript application will = use this |||> |> |> notification however it desires (e.g., cease transmitting to = the |||> |> |> remote peer, provide a notification to the user, etc.). |||> |> | |||> |> |This seems to me like it will not fulfill the goal set in the abst= ract: |||> |> |"to ensure that a malicious JavaScript cannot use the browser as a |||> |> |platform for launching attacks". If the JavaScript is free to igno= re the |||> |> |notification from the browser, then it has no security benefits. I= f you |||> |> |want to reach that goal, the browser needs to forcefully stop tran= smitting. |||> |> |||> |> That goal is fulfilled by the consent checks -- the browser would s= top transmitting everything ||on |||> |that candidate pair, including liveness checks, if there is a consent= failure. |||> | |||> |That's not what the draft says. It says that the browser "notifies" t= he |||> |JS app. It needs to say that the browser MUST stop sending. |||> |||> No. That section is about liveness check and its intention is just not= ify the JavaScript of a |||potential connectivity loss. It is when the consent check fails the brow= ser actually stops sending |||everything. Does the draft need more text on the distinction between con= sent and liveness tests? ||| |||Ah! No, you're right, and the text is already perfectly clear about |||this. No need to change. I was just confused. ||| |||> |> |> When not actively sending traffic on a nominated candidate pa= ir, |||> |> |> performing consent freshness does not serve any purpose from = a |||> |> |> security perspective. |||> |> | |||> |> |I don't understand what this means. Why is the "security perspecti= ve" |||> |> |important here? Aren't we concerned about keepalives? |||> |> |||> |> You mean one could use keepalives (Binding indications) for launchi= ng attacks, so consent |||freshness |||> |would be required for sending them as well? |||> | |||> |No. |||> | |||> |This is a section about keepalives. I just don't understand this |||> |sentence, and I don't understand why it talks about security. |||> |||> Ok, let me elaborate: |||> - Consent freshness is not necessary when the browser is not sending a= ny |||> traffic on a candidate pair. |||> - If the browser is not performing consent freshness on a candidate pa= ir |||> for the above reason, it performs ICE keepalives (or RTP keepalives)= to |||> refresh NAT bindings. |||> |||> Of course, the browser could continue performing consent freshness eve= n when it is not sending any |||other traffic on that candidate pair and skip ICE keepalives. ||| |||Ah, ok I understand with your explanation. It makes sense. There should |||be a way to reformulate the text to make it clearer. ||| |||Thanks, |||Simon |||_______________________________________________ |||rtcweb mailing list |||rtcweb@ietf.org |||https://www.ietf.org/mailman/listinfo/rtcweb From mperumal@cisco.com Thu Jul 18 03:28:58 2013 Return-Path: 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 687DD21E80CB for ; Thu, 18 Jul 2013 03:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TPnXVIx1KQdA for ; Thu, 18 Jul 2013 03:28:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1359921E80C8 for ; Thu, 18 Jul 2013 03:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10861; q=dns/txt; s=iport; t=1374143333; x=1375352933; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nqHELum5M6wvmEf+/2651Cu9Ve5zkjw27doWclXsolE=; b=Idl2NqAQfUQnfHdTAIpIH9/P2PXrj0O8yP/Zk8WMz+PIyBpkSo6jcBY9 uHt99tWcHyfKB+JNDQbeR5QzBlo2Zcpot36yBaHvW9l9O/ObG5RziNVem wLzcOp9RP1HDL/IPE/BpZAOec3Y5qhnrjxGJirFgQv9H7TucFBouURFu8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAM7B51GtJXG+/2dsb2JhbABagwY0UMA+gQ8WdIIjAQEBAQMBAQFrCwwEAgEIEQQBAQsdBycLFAgBCAIEDgUIE4d1DLZRBI9JBisHBoMHbgOIb6A6gVmBOYFoBQI5 X-IronPort-AV: E=Sophos;i="4.89,692,1367971200"; d="scan'208";a="236383016" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jul 2013 10:28:52 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6IASqWs016784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 10:28:52 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 05:28:51 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Avasarala, Ranjit (NSN - IN/Bangalore)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoCAAAceUIAAG3TAgAAKkwCAAFNjgIABRHCQgAAS5sA= Date: Thu, 18 Jul 2013 10:28:50 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 10:28:58 -0000 |-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.= com] |Sent: Thursday, July 18, 2013 2:51 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |One more question - Would consent freshness be an additional feature as pa= rt of ICE functionality? Yes. | |Regards |Ranjit | | | |-----Original Message----- |From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |Sent: Wednesday, July 17, 2013 7:48 PM |To: Avasarala, Ranjit (NSN - IN/Bangalore) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | ||-----Original Message----- ||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn= .com] ||Sent: Wednesday, July 17, 2013 2:36 PM ||To: Muthu Arul Mozhi Perumal (mperumal) ||Cc: rtcweb@ietf.org ||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||My comments inline || ||Regards ||Ranjit || ||-----Original Message----- ||From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] ||Sent: Wednesday, July 17, 2013 2:16 PM ||To: Avasarala, Ranjit (NSN - IN/Bangalore) ||Cc: rtcweb@ietf.org ||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || |||If many public STUN servers and call servers that implement STUN or ICEl= ite |||functionalities, are not expected to support || ||I should have said they have no role to play. It is similar to peer-to-pe= er ICE connectivity checks - |- ||those checks don't go through public STUN or call servers at all. ||[Ranjit] But there can be scenarios where RTCWebBrowsers do talk to WebRT= C Gateways which could be |co- ||located with call handling servers. Then it won't make sense to have this= feature. | |An RTCWeb gateway wouldn't have to do anything fancier than what it alread= y does for ICE connectivity |checks. | || ||The difference between ICE connectivity checks and consent freshness chec= ks is that the former is ||performed before session establishment and the later is performed after s= ession establishment. ||[Ranjit] Why do you need to check consent of the peer after session is es= tablished? Ideally I should ||check consent before session establishment. If the peer does not want to = receive traffic, then |session ||itself should not be established. | |See draft-ietf-rtcweb-security-arch: | | |4.4. Communications and Consent Freshness | | From a security perspective, everything from here on in is a little | anticlimactic: Alice and Bob exchange data protected by the keys | negotiated by DTLS. Because of the security guarantees discussed in | the previous sections, they know that the communications are | encrypted and authenticated. | | The one remaining security property we need to establish is "consent | freshness", i.e., allowing Alice to verify that Bob is still prepared | to receive her communications so that Alice does not continue to send | large traffic volumes to entities which went abruptly offline. ICE | specifies periodic STUN keepalizes but only if media is not flowing. | Because the consent issue is more difficult here, we require RTCWeb | implementations to periodically send keepalives. As described in | Section 5.3, these keepalives MUST be based on the consent freshness | mechanism specified in [I-D.muthu-behave-consent-freshness]. If a | keepalive fails and no new ICE channels can be established, then the | session is terminated. | | || |||then who would have interest to support this functionality? || ||RTCWEB browsers and browser-like platforms. ||[Ranjit] browser may implement, but it would be very customized one. I do= not think the intermediate ||entities would want to support. | |You seem to be completely missing the very purpose of consent. | || |||Ideally getting consent for receiving traffic or call should be part of = signaling. |||I do not think using STUN is appropriate. || ||ICE already does that. You think it is inappropriate? ||[Ranjit] I am saying that using STUN for consent check is not appropriate= as STUN has other dedicated ||functionality to do - like connectivity checks, keep alives, etc. | |See draft-ietf-rtcweb-security and draft-ietf-rtcweb-security. | ||Also in cases of Symmetric NATs where STUN fails, TURN is needed. Then th= e proposed feature would |anyway fail. | |The solution is built on top of ICE, so should work across these. | |Muthu | || ||Muthu || |||-----Original Message----- |||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@ns= n.com] |||Sent: Wednesday, July 17, 2013 12:16 PM |||To: Muthu Arul Mozhi Perumal (mperumal) |||Cc: rtcweb@ietf.org |||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consen= t-freshness-04.txt ||| |||Hi Muthu ||| |||If many public STUN servers and call servers that implement STUN or ICEl= ite functionalities, are not |||expected to support, then who would have interest to support this functi= onality? Ideally getting |||consent for receiving traffic or call should be part of signaling. I do = not think using STUN is |||appropriate. ||| |||Regards |||Ranjit ||| ||| ||| ||| |||-----Original Message----- |||From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com= ] |||Sent: Wednesday, July 17, 2013 12:07 PM |||To: Avasarala, Ranjit (NSN - IN/Bangalore) |||Cc: rtcweb@ietf.org; behave@ietf.org |||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consen= t-freshness-04.txt ||| |||Ranjit, ||| ||||Many publicly available STUN servers or those that are part of Call ser= vers ||||may not support this. ||| |||Public STUN servers and call servers are not expected to support this. ||| ||||Can't there be some other neutral mechanism to query peer's consent - t= hrough ||||signaling? ||| |||No. That signaling between the JS and the web server could be anything (= SIP or XMPP or proprietary |or |||whatever) and the browser has no control over it. ||| |||Muthu ||| ||||-----Original Message----- ||||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@n= sn.com] ||||Sent: Wednesday, July 17, 2013 11:19 AM ||||To: Muthu Arul Mozhi Perumal (mperumal) ||||Cc: rtcweb@ietf.org; behave@ietf.org ||||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-conse= nt-freshness-04.txt |||| ||||Hi Muthu |||| ||||Though using STUN request/response may be good for querying about conse= nt, I feel it is overloading ||||the functionality of STUN. Many publicly available STUN servers or thos= e that are part of Call |||servers ||||may not support this. |||| ||||Can't there be some other neutral mechanism to query peer's consent - t= hrough signaling? |||| |||| ||||Regards ||||Ranjit |||| |||| |||| ||||-----Original Message----- ||||From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behal= f Of ext Simon Perreault ||||Sent: Tuesday, July 16, 2013 6:34 PM ||||To: Muthu Arul Mozhi Perumal (mperumal) ||||Cc: rtcweb@ietf.org; behave@ietf.org ||||Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-conse= nt-freshness-04.txt |||| ||||Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : ||||> |> |> Liveness timer: If no packets have been received on the loca= l port in ||||> |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript th= at ||||> |> |> connectivity has been lost. The JavaScript application will= use this ||||> |> |> notification however it desires (e.g., cease transmitting to= the ||||> |> |> remote peer, provide a notification to the user, etc.). ||||> |> | ||||> |> |This seems to me like it will not fulfill the goal set in the abs= tract: ||||> |> |"to ensure that a malicious JavaScript cannot use the browser as = a ||||> |> |platform for launching attacks". If the JavaScript is free to ign= ore the ||||> |> |notification from the browser, then it has no security benefits. = If you ||||> |> |want to reach that goal, the browser needs to forcefully stop tra= nsmitting. ||||> |> ||||> |> That goal is fulfilled by the consent checks -- the browser would = stop transmitting everything |||on ||||> |that candidate pair, including liveness checks, if there is a consen= t failure. ||||> | ||||> |That's not what the draft says. It says that the browser "notifies" = the ||||> |JS app. It needs to say that the browser MUST stop sending. ||||> ||||> No. That section is about liveness check and its intention is just no= tify the JavaScript of a ||||potential connectivity loss. It is when the consent check fails the bro= wser actually stops sending ||||everything. Does the draft need more text on the distinction between co= nsent and liveness tests? |||| ||||Ah! No, you're right, and the text is already perfectly clear about ||||this. No need to change. I was just confused. |||| ||||> |> |> When not actively sending traffic on a nominated candidate p= air, ||||> |> |> performing consent freshness does not serve any purpose from= a ||||> |> |> security perspective. ||||> |> | ||||> |> |I don't understand what this means. Why is the "security perspect= ive" ||||> |> |important here? Aren't we concerned about keepalives? ||||> |> ||||> |> You mean one could use keepalives (Binding indications) for launch= ing attacks, so consent ||||freshness ||||> |would be required for sending them as well? ||||> | ||||> |No. ||||> | ||||> |This is a section about keepalives. I just don't understand this ||||> |sentence, and I don't understand why it talks about security. ||||> ||||> Ok, let me elaborate: ||||> - Consent freshness is not necessary when the browser is not sending = any ||||> traffic on a candidate pair. ||||> - If the browser is not performing consent freshness on a candidate p= air ||||> for the above reason, it performs ICE keepalives (or RTP keepalives= ) to ||||> refresh NAT bindings. ||||> ||||> Of course, the browser could continue performing consent freshness ev= en when it is not sending |any ||||other traffic on that candidate pair and skip ICE keepalives. |||| ||||Ah, ok I understand with your explanation. It makes sense. There should ||||be a way to reformulate the text to make it clearer. |||| ||||Thanks, ||||Simon ||||_______________________________________________ ||||rtcweb mailing list ||||rtcweb@ietf.org ||||https://www.ietf.org/mailman/listinfo/rtcweb From coverdale@sympatico.ca Thu Jul 18 05:25:55 2013 Return-Path: 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 EBFF911E8132 for ; Thu, 18 Jul 2013 05:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] 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 klkmw3UgHbz9 for ; Thu, 18 Jul 2013 05:25:51 -0700 (PDT) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB4C11E813D for ; Thu, 18 Jul 2013 05:25:50 -0700 (PDT) Received: from BLU0-SMTP56 ([65.55.116.72]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 05:25:49 -0700 X-EIP: [bliq7CIrszVS+SBLyQee+1Wn/+3UMQ7K] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.37.119]) by BLU0-SMTP56.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 05:25:44 -0700 From: Paul Coverdale To: "'Hutton, Andrew'" , "'Bogineni, Kalyani'" , "'Bo Burman'" , References: <20130716170223.B5DD911E80D7@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF1164B89C@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1164B89C@MCHP04MSX.global-ad.net> Date: Thu, 18 Jul 2013 08:25:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6BN11IugiIgzm2TXug3PomYB8N3ABDXdRAACEuDYAAOgsjMA== Content-Language: en-us X-OriginalArrivalTime: 18 Jul 2013 12:25:46.0518 (UTC) FILETIME=[EDF74B60:01CE83B1] Subject: Re: [rtcweb] Some thoughts on optional audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 12:25:56 -0000 Yes, this text has been around for a while. I also support it. ...Paul >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >Of Hutton, Andrew >Sent: Wednesday, July 17, 2013 4:46 AM >To: Bogineni, Kalyani; 'Bo Burman'; rtcweb@ietf.org >Subject: Re: [rtcweb] Some thoughts on optional audio codecs > >We appear to have been around this loop a number of times the text >suggested here is exactly what was suggested by Andrew Allen back in >January and I for one supported it them and still do - See >http://www.ietf.org/mail-archive/web/rtcweb/current/msg06121.html. > >Not sure there was a definitive conclusion to that particular consensus >call. > >Andy > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Bogineni, Kalyani >> Sent: 16 July 2013 18:02 >> To: 'Bo Burman'; rtcweb@ietf.org >> Cc: Bogineni, Kalyani >> Subject: Re: [rtcweb] Some thoughts on optional audio codecs >> >> We support the following wording proposal from Bo Burman. >> >> "If other suitable audio codecs are available to the browser to use, >> it is recommended that they are also included in the offer in order = to >> maximize the possibility to establish the session without the need = for >> audio transcoding". >> >> Regards, >> Kalyani Bogineni >> Verizon >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Bo Burman >> Sent: Monday, July 15, 2013 11:15 AM >> To: rtcweb@ietf.org >> Subject: [rtcweb] Some thoughts on optional audio codecs >> >> Regarding the previous discussion on optional audio codecs in the >> (currently expired) draft on RTCWEB audio codecs >> (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/): >> >> I think most parties involved in WebRTC work, myself included, hope >> and believe that it will be ubiquitous and easy to include real-time >> media conversation functionality in nearly any web context. Since it >> will be that easy, it can be expected that most web developers need >> not be, and thus will not be, media specialists or very knowledgeable >about codecs. >> >> The definition of RTCWEB MTI codecs ensures that communication is >> possible since at least one codec will always be found, but it is not >> possible to claim the resulting communication to be optimum for every >> possible context. >> >> Even if WebRTC will be close to ubiquitous, there will for quite some >> time likely be a desire to reach real-time media domains and devices >> that were not originally designed for and thus are not optimized for >> use with WebRTC. A communication device that is not designed solely >> for WebRTC use will likely include functionality and codecs also for >> its "native" domain. >> >> Any added cost of not being able to use existing "native" codecs will >> vary both in amount and where the cost has to be taken. Eliminating = it >> is indeed an optimization, but the total cost savings may still be >> significant. >> >> With the current design and to my understanding, it will be the >> browser vendor's choice to add optional codecs, including any = "native" >> domain codecs. The choice may possibly be delegated to individual = web >> developers making use of WebRTC functionality. A browser vendor will >> arguably have to know each target platform to some extent, but it can >> hardly be assumed that a web developer knows the capabilities of all >> devices that will use the WebRTC-enabled site unless the browser can >> provide the needed information. There is a risk that "native" codecs >> in devices are not well handled, unless the motivations and methods = to >> make use of them are better specified. >> >> While any audio codecs besides the MTI ones are clearly optional, I >> believe the suggested text addition on optional audio codecs to the >> RTCWEB audio draft in Ticket #12 >> (http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12#) to be too = brief >> considering the above. >> >> In that draft, I would prefer something more in line with: >> >> "If other suitable audio codecs are available to the browser to use, >> it is recommended that they are also included in the offer in order = to >> maximize the possibility to establish the session without the need = for >> audio transcoding". >> >> Assuming that the browser vendor (or web developer) is sufficiently >> concerned with codecs to read the audio codecs draft (or the >> corresponding RFC to-be), the above text may, as a start, give some >> added guidance why non-MTI codecs may be desirable to consider in >> addition to the MTI ones. >> >> Cheers, >> Bo >> >> Multimedia Technologies >> Ericsson Research >> F=E4r=F6gatan 6 >> SE-164 80, Kista, Sweden >> www.ericsson.com >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From rajmohanbanavi@gmail.com Thu Jul 18 05:28:18 2013 Return-Path: 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 8FBA221F8D0D; Thu, 18 Jul 2013 05:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Wi0RqG+PGIVl; Thu, 18 Jul 2013 05:28:17 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id AB68A21F8895; Thu, 18 Jul 2013 05:28:17 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so6968332ied.0 for ; Thu, 18 Jul 2013 05:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/sGhxOCPIg1cfuS5hK+Pf+YrhGs8LYx6AoGDVazxhPk=; b=SvCK1F/zJqqgeWcU0lX7+g4lftHYH+nZIttdZ/7ihMKGQu77XNZw8q+sKf93NyQ5Zq GKPl18RGLxAOExuW3kEPzKAaGuvQbPOey/TNXf17RbaYI9c5JVK4m+Q6xiMP1wpYmJ+d ZYfxCL6scYS1g/wuO66ZzjbE3VQ1AYtsYxX8oWxcFyAR+3wuPKAfWfY+VdZkP6C3JI+p OwRrg6qFnfAxOEkxu7+I+xf8HAfOBIxv9A6QBaEEncK3Qy9GQc7NhbHKDCqvFfCHQOxX FGfx1/cuuP5U4ht9GyPcxhtLp0FT+m7aZKHrDM86jZJJemjWtHJy+T+0xb99exQvjnY6 FPRQ== MIME-Version: 1.0 X-Received: by 10.50.1.78 with SMTP id 14mr2951908igk.60.1374150497256; Thu, 18 Jul 2013 05:28:17 -0700 (PDT) Received: by 10.42.152.9 with HTTP; Thu, 18 Jul 2013 05:28:17 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> Date: Thu, 18 Jul 2013 17:58:17 +0530 Message-ID: From: Rajmohan Banavi To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bdc119a41cf0c04e1c85826 Cc: "rtcweb@ietf.org" , behave Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 12:28:18 -0000 --047d7bdc119a41cf0c04e1c85826 Content-Type: text/plain; charset=ISO-8859-1 Hi Justin, comments inline with additional comments at the end. Correct, but that is a significant advantage, especially when the web and > TURN servers are separate entities. > IMHO, the standard spec should not be based on any specific implementation method. Now I agree that the TURN server validation becomes easier using this method because it does not have to do some sort of lookup. However, some another TURN server implementer can achieve the same functionality by providing REST API but using randomly generated pasword (rather than use HMAC) and using some sort of lookup for TURN username when TURN ALLOCATE request is received. Now lets look at the collateral affects of using this proposed implementation way - TURN server needs to perform MESSAGE-INTEGRITY validation across two secrets (worst case due to key rotation) when TURN ALLOCATE request is received - TURN username needs to consist of entire state (user identifier + expiry time). And upon receiving the ALLOCATE request, TURN server must check if the username is still valid based on expiry time part (of username) - Time sync needs to be maintained across the web server and the TURN server. All of the above are not needed if one does not use the implementation method specified in the draft but still provide REST API to generate ephemeral credentials. How these ephemeral credentials are generated and how the TURN requests are validated is an implementation decision. And it is not desirable to have standards which caters to each implementation method. > The WebRTC client application doesn't see the secret key, this is only > shared between the web and TURN servers. > What does the web server do with the secret key? This is not clear from the text. Additional comments. 1. Sec 4.2 Server - "Note that the REALM value supplied by the server is not meaningful in this context, and can be set to any valid value". Which realm value is being referred here? The REALM attribute value in the 401 challenge response sent by the TURN server (in response to initial ALLOCATE request)? 2. The implementation method proposed is implicit and not clear from the draft text for the reader. The text states that username must be so and so, password must be HMAC processed etc, but it is not clear why these need to be done. It must be made clear somewhere in the draft that these are being proposed to ensure that the TURN server can validate the TURN ALLOCATE requests by performing HMAC on the USERNAME attribute received. And that the TURN server does not have to maintain/store ephemeral credentials. This will help the reader to comprehend the draft in a better way. Hope it is clear. Thanks, Rajmohan Banavi --047d7bdc119a41cf0c04e1c85826 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi =A0Justin, comments inline with additional comments at = the end.

Correct, but that is a significant advantage, especially when the web and = TURN servers are separate entities.=A0
=

IMHO, the standard spec should not be based on any specific = implementation method. Now I agree that the TURN server validation becomes = easier using this method because it does not have to do some sort of lookup= . However, some another TURN server implementer can achieve the same functi= onality by providing REST API but using randomly generated pasword (rather = than use HMAC) and using some sort of lookup for TURN username when TURN AL= LOCATE request is received.

Now lets look at the collateral affects of using this p= roposed implementation way
- TURN server needs to perform MESSAGE= -INTEGRITY validation across two secrets (worst case due to key rotation) w= hen TURN ALLOCATE request is received
- TURN username needs to consist of entire state (user identifier + ex= piry time). And upon receiving the ALLOCATE request, TURN server must check= if the username is still valid based on expiry time part (of username)
- Time sync needs to be maintained across the web server and the TURN = server.

All of the above are not needed if one doe= s not use the implementation method specified in the draft but still provid= e REST API to generate ephemeral credentials. How these ephemeral credentia= ls are generated and how the TURN requests are validated is an implementati= on decision. And it is not desirable to have standards which caters to each= implementation method.=A0
=A0
The WebRTC client application doesn't see the secret key, this is only= shared between the web and TURN servers.

What does the web server do with the secre= t key? This is not clear from the text.

Additional= comments.
  1. Sec 4.2 Server - "Note that the REALM val= ue supplied by the server is not meaningful in this context, and can be set= to any valid value". Which realm value is being referred here? The RE= ALM attribute value in the 401 challenge response sent by the TURN server (= in response to initial ALLOCATE request)?
  2. The implementation method proposed is implicit and not clear from = the draft text for the reader. The text states that username must be so and= so, password must be HMAC processed etc, but it is not clear why these nee= d to be done. It must be made clear somewhere in the draft that these are b= eing proposed to ensure that the TURN server can validate the TURN ALLOCATE= requests by performing HMAC on the USERNAME attribute received. And that t= he TURN server does not have to maintain/store ephemeral credentials. This = will help the reader to comprehend the draft in a better way.
Hope it is clear.

Thanks,
Rajmohan Banavi

--047d7bdc119a41cf0c04e1c85826-- From pthatcher@google.com Thu Jul 18 08:04:21 2013 Return-Path: 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 0FFD211E817B for ; Thu, 18 Jul 2013 08:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.042, 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 rjk9I-y8mgYw for ; Thu, 18 Jul 2013 08:04:18 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8B12D21E8109 for ; Thu, 18 Jul 2013 08:02:12 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wz7so3285704pbc.37 for ; Thu, 18 Jul 2013 08:02:03 -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=ockvWYzXz0sc59C9YtK3RE6M0aYRE5IA+hk1/T9E4hk=; b=FZBM9qwBn6usd3KTPLlSpb1DJyUH7kZ5LBefspMQheo9shqNtg2260AgXwzdLZFW33 o8um165Ws6IdfoDEOnTWpfwqlyqTpF95y01mDvdYc+32dMuiT9t8S7QTRmcE88xoOrq4 pnEJrYY/v1HEDdHfpm69XfuEOV1IN3+65wNVMRM/AhBsWZdRfPnA80ufZbbe36Zn/ntY WkqTaLICR+paezdO9+FcZLdSE0Y4jhaNegiPUC7yE3Pcsc6aCi1q7324nCGAGNxX5++K mu6veHQhWDTmKuCzU2QxWF/b5sIqm/RiCuj6QKFS76YJeSJfdxxjsy10Sli8z4/NkXEw rWaw== 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=ockvWYzXz0sc59C9YtK3RE6M0aYRE5IA+hk1/T9E4hk=; b=nCouatMmigu6Gwc05srJ5EiBU8fLfoCjIWKs9GQiBoZRPymqqfzr0ffdKl+uZ9FkvB 83kiRsmWoATYkjoGlYhNSp/7N8DW2QwQzKtCrhojKU9Go1kfmMBnuCBXv5muGDTo8CNR 5ILVUgjd/5/ZUol0X0gJ/NeVLS2ryAvD5ztPXZ9hgV6f14pubrnEZeGYW9trHCLUdJuu 7h939yoycA8afKUZJp4KCQ/EhV/L37fqMH9IOqUl6eXNH9CLmCgDgL+ZBXeZlkKhA2zF Gedf+agsRo8zCezLq98vOm716xBatsbeFGi7spg9x5OgbQ5FkO7JFEK7pqm7K1FlEx2r 1o5A== X-Received: by 10.66.14.196 with SMTP id r4mr13798315pac.57.1374159722844; Thu, 18 Jul 2013 08:02:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Thu, 18 Jul 2013 08:01:22 -0700 (PDT) In-Reply-To: <51E77362.7070801@alvestrand.no> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E77362.7070801@alvestrand.no> From: Peter Thatcher Date: Thu, 18 Jul 2013 08:01:22 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec51f99e5253bb004e1ca7ee9 X-Gm-Message-State: ALoCoQn94sE3D73WPGYoltCIQ5SotnVSgrrQvkCfgBu7GoWeapiQsX+z5Ju483eITTHGl/LW2VN4Kdp6Wsm/iuwIyOOF3yJae2yuV2Fbiw+97Fh5xp0cEYoyopr8Dtxp0Os0sH3E6cnpzfPxT8utL/2Hr25hPf13tQAYBH2kcTykw4FDrrBm2rZateVLgebaMkncBwWSFxaR Cc: "" Subject: Re: [rtcweb] e= lines (Re: Summary of Application Developers' opinions ..) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:04:21 -0000 --bcaec51f99e5253bb004e1ca7ee9 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 17, 2013 at 9:47 PM, Harald Alvestrand wrote: > Matthew, thanks for sending 12 messages in 3 hours to the mailing list. > > Given how many active threads and subthreads are going on at once, 12 messages doesn't seem like that many. I've lost track of how many centithreads there are now. > Just one point on which I corrected you before, but since I see you're > repeating it: > > On 07/17/2013 11:58 PM, Matthew Kaufman (SKYPE) wrote: > > - What if someone adds an r= or p= or e=? > > The code for handling an e= line has been in Chrome since a very early > release. > You claimed in Lyon that you'd tested it and failed to have it parse, > but I never saw the test case; you may have inserted it into the wrong > place, rendering the SDP invalid. > > The SDP specification is quite strict about the order of these fields, > exactly to make it simpler to write parsers. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec51f99e5253bb004e1ca7ee9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 17, 2013 at 9:47 PM, Harald Alvestrand <ha= rald@alvestrand.no> wrote:
Matthew, thanks for sending 12 messages in 3= hours to the mailing list.


Given how many active threads and subt= hreads are going on at once, 12 messages doesn't seem like that many. = =C2=A0I've lost track of how many centithreads there are now.
=C2=A0
=C2=A0
Just one point on which I corrected you before, but since I see you're<= br> repeating it:

On 07/17/2013 11:58 PM, Matthew Kaufman (SKYPE) wrote:
> - What if someone adds an r=3D or p=3D or e=3D?

The code for handling an e=3D line has been in Chrome since a very early release.
You claimed in Lyon that you'd tested it and failed to have it parse, but I never saw the test case; you may have inserted it into the wrong
place, rendering the SDP invalid.

The SDP specification is quite strict about the order of these fields,
exactly to make it simpler to write parsers.

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

--bcaec51f99e5253bb004e1ca7ee9-- From matthew.kaufman@skype.net Thu Jul 18 08:07:46 2013 Return-Path: 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 5C6B111E8182 for ; Thu, 18 Jul 2013 08:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.958 X-Spam-Level: X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, HTML_MESSAGE=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 3u0d7ynce35V for ; Thu, 18 Jul 2013 08:07:41 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5E521F8EE6 for ; Thu, 18 Jul 2013 08:06:53 -0700 (PDT) Received: from mail49-db9-R.bigfish.com (10.174.16.242) by DB9EHSOBE013.bigfish.com (10.174.14.76) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 15:06:52 +0000 Received: from mail49-db9 (localhost [127.0.0.1]) by mail49-db9-R.bigfish.com (Postfix) with ESMTP id 924EA3C01F7; Thu, 18 Jul 2013 15:06:52 +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: -24 X-BigFish: VS-24(zzbb2dI98dI9371I148cIc85dhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL18c673h1de097h1de096h8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail49-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=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail49-db9 (localhost.localdomain [127.0.0.1]) by mail49-db9 (MessageSwitch) id 1374160010545913_16689; Thu, 18 Jul 2013 15:06:50 +0000 (UTC) Received: from DB9EHSMHS019.bigfish.com (unknown [10.174.16.254]) by mail49-db9.bigfish.com (Postfix) with ESMTP id 769AD20048; Thu, 18 Jul 2013 15:06:50 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS019.bigfish.com (10.174.14.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 18 Jul 2013 15:06:49 +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; Thu, 18 Jul 2013 15:06:47 +0000 From: "Matthew Kaufman (SKYPE)" To: Peter Thatcher , Harald Alvestrand Thread-Topic: [rtcweb] e= lines (Re: Summary of Application Developers' opinions ..) Thread-Index: AQHOg3H6C1QS7WP740Kwrfdnz1pKNZlqiHAAgAABWc0= Date: Thu, 18 Jul 2013 15:06:46 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E77362.7070801@alvestrand.no>, In-Reply-To: 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: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A484237147CBTK5EX14MBXC266r_" MIME-Version: 1.0 X-OriginatorOrg: skype.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "" Subject: Re: [rtcweb] e= lines (Re: Summary of Application Developers' opinions ..) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:07:46 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A484237147CBTK5EX14MBXC266r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable By waiting, I reduced what would have been 30 or 40 messages to "only" 12. = Just pretend that I spaced them out over the course of the discussion and b= e happy. Matthew Kaufman ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Peter = Thatcher [pthatcher@google.com] Sent: Thursday, July 18, 2013 8:01 AM To: Harald Alvestrand Cc: Subject: Re: [rtcweb] e=3D lines (Re: Summary of Application Developers' op= inions ..) On Wed, Jul 17, 2013 at 9:47 PM, Harald Alvestrand > wrote: Matthew, thanks for sending 12 messages in 3 hours to the mailing list. Given how many active threads and subthreads are going on at once, 12 messa= ges doesn't seem like that many. I've lost track of how many centithreads = there are now. Just one point on which I corrected you before, but since I see you're repeating it: On 07/17/2013 11:58 PM, Matthew Kaufman (SKYPE) wrote: > - What if someone adds an r=3D or p=3D or e=3D? The code for handling an e=3D line has been in Chrome since a very early release. You claimed in Lyon that you'd tested it and failed to have it parse, but I never saw the test case; you may have inserted it into the wrong place, rendering the SDP invalid. The SDP specification is quite strict about the order of these fields, exactly to make it simpler to write parsers. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_AE1A6B5FD507DC4FB3C5166F3A05A484237147CBTK5EX14MBXC266r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
By waiting, I reduced what would have been 30 or 40 messages to &quo= t;only" 12. Just pretend that I spaced them out over the course of the= discussion and be happy.

Matthew Kaufman

From: rtcweb-bounces@ietf.org [rtcweb-bou= nces@ietf.org] on behalf of Peter Thatcher [pthatcher@google.com]
Sent: Thursday, July 18, 2013 8:01 AM
To: Harald Alvestrand
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] e=3D lines (Re: Summary of Application Develop= ers' opinions ..)

On Wed, Jul 17, 2013 at 9:47 PM, Harald Alvestrand <harald@alvest= rand.no> wrote:
Matthew, thanks for sending 12 messages in 3 hours to the mailing list.


Given how many active threads and subthreads are going on at once, 12 = messages doesn't seem like that many.  I've lost track of how many cen= tithreads there are now.
 
 
Just one point on which I corrected you before, but since I see you're
repeating it:

On 07/17/2013 11:58 PM, Matthew Kaufman (SKYPE) wrote:
> - What if someone adds an r=3D or p=3D or e=3D?

The code for handling an e=3D line has been in Chrome since a very early release.
You claimed in Lyon that you'd tested it and failed to have it parse,
but I never saw the test case; you may have inserted it into the wrong
place, rendering the SDP invalid.

The SDP specification is quite strict about the order of these fields,
exactly to make it simpler to write parsers.

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

--_000_AE1A6B5FD507DC4FB3C5166F3A05A484237147CBTK5EX14MBXC266r_-- From pthatcher@google.com Thu Jul 18 08:12:46 2013 Return-Path: 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 407CA11E814C for ; Thu, 18 Jul 2013 08:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, 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 DY0kkam-NZ6C for ; Thu, 18 Jul 2013 08:12:45 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6245311E80E1 for ; Thu, 18 Jul 2013 08:12:45 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so3269866pbc.25 for ; Thu, 18 Jul 2013 08:12:45 -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=5zHqGYSGSJ0v3YuzO0CO8cYRRyxd9Xb7SEqmxElq0jg=; b=lu3nV2ys3j0eHJoiknpDFCfK5AruDrmd9Z0Q1xe3yTTmUi8WJS4Q0r6nNNfjzHTEFy aeNiyoGl2V2KFomB5P2XCKfyMTtwJGQspmC4CNsX3poHMDx1+geLKvSrEbgtOybY/oi1 k4ns88dNAi/yibSuY0kRh2WvTFvJr6DXW/I49pDk8r9oeT3daeZpvgdrRaSGI1UqTZhW D33sFMOf44T9FVMGO7CSOSseFFJr7kWEx25R1KAYNIlHM/zjt030aOybbhDdaPsmo6Zz pPW+EQw39JBgj4Hw8OXA49btnu4xaQ4rN+NsGuOj9HEM9UcxrElfTknjasEco9Nzm6ED YfuA== 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=5zHqGYSGSJ0v3YuzO0CO8cYRRyxd9Xb7SEqmxElq0jg=; b=ivj6tmJgqDQ1L4k4JEgMqFyWg+IgJWVHBNQRpYzJ2whzVNDP1HSWZ9AXdVmztrSyS3 LGEYt3iMN+qpy+DrSLNIXCc0ZFSDMQ9wGe8kVZiAbPtyCsNjEv4ulWC9uOAyiHvt2Tj0 yRpgwEvRma6BR5Bxs64VbWlDFK22+0gRU1NbVpfurqLi0ZpxDAMJd9CCeLr02/yyr02A XdpQsagdcNuNmltHB8BOMrQiNVfBVGOo3fEpWdSO67yo9TxVX4qgQ/YZ01IIz9BfUVDb wAQMdi+2YwGdHaVWqKnIVcxgRiVSeou7P7reR7N84KVqW8Vtlqt0AwLCfU61uxnbfXs6 EsOQ== X-Received: by 10.68.29.2 with SMTP id f2mr12534369pbh.184.1374160365024; Thu, 18 Jul 2013 08:12:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Thu, 18 Jul 2013 08:12:04 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Thu, 18 Jul 2013 08:12:04 -0700 Message-ID: To: "Matthew Kaufman (SKYPE)" Content-Type: multipart/alternative; boundary=bcaec520f3b96c1b5604e1caa4c7 X-Gm-Message-State: ALoCoQmmO6xv8MqAxHehB2Wdbq2wL0924LTTwuEg7X9osjf7KsLYVZrWraD6If1J1DAUCjRH8bJP+ZH7bIyUDlUvvVcND8IAh/B8g7f9KbgTcqi/cDwqfqNHDMEKjVNK6O1oMEE6Sz4PwGbjgljLnG1oD/iPM0p4EV4TdSbKxSko4LxHGlKtrsS8rEH2q7dwWDW+xqyIzINl Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:12:46 -0000 --bcaec520f3b96c1b5604e1caa4c7 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 17, 2013 at 2:58 PM, Matthew Kaufman (SKYPE) < matthew.kaufman@skype.net> wrote: > Bernard Aboba: > > > > The problem was that we never defined what mangling browsers had to > > support. Given all the SDP specs that is actually a huge work item. > > > This is exactly what my slides that weren't presented last November > started to touch upon. It only takes a few minutes with RFC3264 and its > references to start documenting cases that are clearly "valid SDP > offer/answer" and yet for which I cannot for the life of me figure out what > a browser should do if they're presented. > 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. > > Just off the top of my head: > > Can I... > - Change the t= line to be something other than t=0 0? > - Change the rtpmap associations before calling setLocal? > - Change a=sendrecv to a=recvonly before calling setLocal? > - What do you do when you see a=content:sl ? > - What if someone adds an r= or p= or e=? > - What is the RFC that describes a=group:BUNDLE (as seen in some browser > implementations)? > - Can I remove a=group:BUNDLE (or add it) before calling setLocal? > - How about removing a=rtcp-mux? > - Should I do something special at my end if you set > a=ice-options:google-ice ? > - If you put a=ssrc lines in there, can I change the ssrc before passing > it back to setLocal? > - Can I delete the a=ssrc lines? > - Is a=rtcp:1 IN IP4 0.0.0.0 valid or not? > - What about 0.0.0.0 in the o= line? > - If I get a bunch of a=candidate lines, can I swap them around to change > the priority before calling setLocal? > - What if someone claims SAVP instead of SAVPF but gives me rtcp info? > > At the *very least* for each and every line that comes from createOffer > and createAnswer you must be able to answer the following: > - Can I delete it? > - Duplicate it? > - Change it? > - If not, how are violation handled? (Both when passed to another browser > at the far end and when these modifications happen before calling setLocal) > - And can I add additional valid SDP to what came from createOffer or > createAnswer and pass it back to setLocal or not? > > We appear to be nowhere near a document which explains the answers to > these questions, certainly not in the W3C WG, and not in any IETF RFC or > draft I can locate. > > Matthew Kaufman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec520f3b96c1b5604e1caa4c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 17, 2013 at 2:58 PM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:
Bernard Aboba:
>
> The problem was that we never defined what mangling browsers had to > support. Given all the SDP specs that is actually a huge work item.

This is exactly what my slides that weren't presented last Novemb= er started to touch upon. It only takes a few minutes with RFC3264 and its = references to start documenting cases that are clearly "valid SDP offe= r/answer" and yet for which I cannot for the life of me figure out wha= t a browser should do if they're presented.

I believe I began paying attention to the = mailing lists after you sent out theses slides that you didn't present.= =C2=A0I'm interested in seeing them, and while I could dig through arc= hives to find them, if convenient, could you please give me a link to the s= lides? =C2=A0Thanks.=C2=A0
=C2=A0

Just off the top of my head:

Can I...
- Change the t=3D line to be something other than t=3D0 0?
- Change the rtpmap associations before calling setLocal?
- Change a=3Dsendrecv to a=3Drecvonly before calling setLocal?
- What do you do when you see a=3Dcontent:sl ?
- What if someone adds an r=3D or p=3D or e=3D?
- What is the RFC that describes a=3Dgroup:BUNDLE (as seen in some browser = implementations)?
- Can I remove a=3Dgroup:BUNDLE (or add it) before calling setLocal?
- How about removing a=3Drtcp-mux?
- Should I do something special at my end if you set a=3Dice-options:google= -ice ?
- If you put a=3Dssrc lines in there, can I change the ssrc before passing = it back to setLocal?
- Can I delete the a=3Dssrc lines?
- Is a=3Drtcp:1 IN IP4 0.0.0.0 valid or not?
- What about 0.0.0.0 in the o=3D line?
- If I get a bunch of a=3Dcandidate lines, can I swap them around to change= the priority before calling setLocal?
- What if someone claims SAVP instead of SAVPF but gives me rtcp info?

At the *very least* for each and every line that comes from createOffer and= createAnswer you must be able to answer the following:
- Can I delete it?
- Duplicate it?
- Change it?
- If not, how are violation handled? (Both when passed to another browser a= t the far end and when these modifications happen before calling setLocal)<= br> =C2=A0- And can I add additional valid SDP to what came from createOffer or= createAnswer and pass it back to setLocal or not?

We appear to be nowhere near a document which explains the answers to these= questions, certainly not in the W3C WG, and not in any IETF RFC or draft I= can locate.



Matthew Kaufman

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

--bcaec520f3b96c1b5604e1caa4c7-- From pthatcher@google.com Thu Jul 18 08:20:03 2013 Return-Path: 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 2260A21E810D for ; Thu, 18 Jul 2013 08:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.072, 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 6UwHSnRGrnWv for ; Thu, 18 Jul 2013 08:20:02 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 64C5821E8105 for ; Thu, 18 Jul 2013 08:19:58 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so3358469pab.27 for ; Thu, 18 Jul 2013 08:19:58 -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=pgR6/hEoL4INaePIIfhtQs9wGysghtf/gfULjU5+59w=; b=dYOJiVg0twH1r/KmWSg2ZybjcECGxvV4J2HvYYVPrw8Xaw3onCcDOGKpYzpNbaDFH3 nt1nnsSEXunDFJ3RV8/iR/sZjP/F4WVqUnLbsz1Q6C7y8BQH2eYvsoaJwGeN8aIRGNdz c3eR4luHqlLg0tAZQz/H1IVNttkUJTvFRJhaFS6AvBYZvC5qEVnPjkIGxTXtgpTblitq 0WkbPCHlV63UptYRP1+v+y5nJHrTs2tvSzhIDSaOKbSR8lDKvqLKyJchVwvM42vK4EgR hLMpQJXSo212IBFtzPtGybCApqBpVKRtSMnU/cYmpqQVq3yEDwNFWjpMhTXhxHJRC3VL zo8A== 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=pgR6/hEoL4INaePIIfhtQs9wGysghtf/gfULjU5+59w=; b=m0KpcfKAZ2TXNVYcT8o4yQs3Nr/8uiXAXfhnBguHMQa/QpI/zEPWMpuFg5QhhIf0Wb LpU9IBbnvon+9pzhNKLcNDvdXEYpPzj8SbIoTIEaE4FAYN7+mE7pROWC6MMOswYHBn8+ zpkHXbtYTAebJdE2ZXdfdAGuAH3CBlDMbvTa/w9OaJ1Tb/VchR7s1CPkeCvkCKeE4yH1 DjATrquNeBSsIFpADUoGetidN8iEMz6ynG2lbggEoYZUpBio6RPF9RmarUqkwqNyV90i Gl/cyIEBH7BCZB0VDseu39zd3IP9JqfdI+puYewlpG5BpoqnR1hGh4z5XFMY+Pzk9r+v q7EQ== X-Received: by 10.66.142.5 with SMTP id rs5mr13822086pab.168.1374160798088; Thu, 18 Jul 2013 08:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Thu, 18 Jul 2013 08:19:18 -0700 (PDT) In-Reply-To: References: <20130715203130.5677.31855.idtracker@ietfa.amsl.com> From: Peter Thatcher Date: Thu, 18 Jul 2013 08:19:18 -0700 Message-ID: To: Michael Tuexen Content-Type: multipart/alternative; boundary=001a11330f2a3c291504e1cabeff X-Gm-Message-State: ALoCoQk/EZQmWNZ3XipwSNdAx2KTw5odtxd29/qRcMysZoV4VyDz6xH43hZNecuTsaxEYdWy8k3jD7M/t9giWR/jOIvxPWiE8wVOtljmU9cJ10OVCPAOruE6OhTtmXOqGsz57MpwO6Lus30xwj6juuPzLNco6wHZhKKtgggeI6RQiDHtozUcv1RfhbwPPfz6ldWAY5qQC52k Cc: Randell Jesup , "" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:20:03 -0000 --001a11330f2a3c291504e1cabeff Content-Type: text/plain; charset=UTF-8 On Thu, Jul 18, 2013 at 2:11 AM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > On Jul 16, 2013, at 2:43 AM, Peter Thatcher wrote: > > > Hey Randell, can you give a short summary of the changes, if any, that I > would or other implementors would need to know about? > Hi Peter, > > using > > http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-jesup-rtcweb-data-protocol-04.txt&url2=http://tools.ietf.org/id/draft-ietf-rtcweb-data-protocol-00.txt > you see that in addition to clarifications and cleanups > Oh, now that's a slick tool. Thanks for the link. > * external negotiation of data channels is described > * the packet format of the DATA_CHANNEL_OPEN message as been changed > I just wrote the code to serialize and deserialize that message. Please tell me we're not going to change it again :). > Both of these changes require code changes. > > Best regards > Michael > > > > > > On Mon, Jul 15, 2013 at 1:31 PM, wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Real-Time Communication in > WEB-browsers Working Group of the IETF. > > > > Title : WebRTC Data Channel Protocol > > Author(s) : Randell Jesup > > Salvatore Loreto > > Michael Tuexen > > Filename : draft-ietf-rtcweb-data-protocol-00.txt > > Pages : 11 > > Date : 2013-07-15 > > > > Abstract: > > The Web Real-Time Communication (WebRTC) working group is charged to > > provide protocols to support for direct interactive rich > > communication using audio, video, and data between two peers' web- > > browsers. This document specifies an actual (minor) protocol for how > > the JS-layer DataChannel objects provide the data channels between > > the peers. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11330f2a3c291504e1cabeff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jul 18, 2013 at 2:11 AM, Michael Tuexen &= lt;Mi= chael.Tuexen@lurchi.franken.de> wrote:
On Jul 16, 2013, at 2:43 AM, Peter That= cher <pthatche= r@google.com> wrote:

> Hey Randell, can you give a short summary of the changes, if any, that= I would or other implementors would need to know about?
Hi Peter,

using
http://tools.ietf.= org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-jesup-rtcweb-data-protoco= l-04.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-rtcweb-data-protoco= l-00.txt
you see that in addition to clarifications and cleanups

Oh, now that's a slick tool. =C2=A0Thanks for the link= .
=C2=A0
* external negotiation of data channels is described
* the packet format of the DATA_CHANNEL_OPEN messa= ge as been changed

I just wrote the code to serialize and des= erialize that message. =C2=A0Please tell me we're not going to change i= t again :).
=C2=A0
Both of these changes require code changes.

Best regards
Michael
>
>
> On Mon, Jul 15, 2013 at 1:31 PM, <internet-drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> =C2=A0This draft is a work item of the Real-Time Communication in WEB-= browsers Working Group of the IETF.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := WebRTC Data Channel Protocol
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Randell J= esup
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Salvatore Loreto
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Michael Tuexen
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draf= t-ietf-rtcweb-data-protocol-00.txt
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 11
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: 2013-07-15
>
> Abstract:
> =C2=A0 =C2=A0The Web Real-Time Communication (WebRTC) working group is= charged to
> =C2=A0 =C2=A0provide protocols to support for direct interactive rich<= br> > =C2=A0 =C2=A0communication using audio, video, and data between two pe= ers' web-
> =C2=A0 =C2=A0browsers. =C2=A0This document specifies an actual (minor)= protocol for how
> =C2=A0 =C2=A0the JS-layer DataChannel objects provide the data channel= s between
> =C2=A0 =C2=A0the peers.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb= -data-protocol
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-rtcweb-data-pro= tocol-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--001a11330f2a3c291504e1cabeff-- From fineberg@vline.me Thu Jul 18 08:43:21 2013 Return-Path: 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 C0F6821F95EF for ; Thu, 18 Jul 2013 08:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, HTML_MESSAGE=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 LabB6ou+Xlnd for ; Thu, 18 Jul 2013 08:43:11 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 39C8D21F9477 for ; Thu, 18 Jul 2013 08:43:11 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so3211270pdi.13 for ; Thu, 18 Jul 2013 08:43:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=hpzGPQhpk8JMByqmNxRrcT/hkDVGpgHxlgsj4Ckl7i4=; b=GKoAI54SKMPtQQ3iJ+C3ym6lluRM3K27NbjVUZ4Jxut27+j1U74y3XOkuhNcqmSumI TiQMpLunbYKbbMsmfo51TgerNPxxACGvED7iO2Ge0W5zV2kIy2G8LnMcUjPz/G4f6gHY tVNeP1hle77V3lvsfBSC2j60KXVuA5A6xSFRMs5YU+dDM8yD+HU29wIGgSUA6x8B/9LM KLOYKLldKhNjSG7dSvmIjDKG0e4mLLlHy35Q9m8gtFSSZobfhN2gviXJbPYF4rIgHrK4 eurQ40SSK8qi4tqC5jayCOw2oyHtwaq/OIhEIGRiP29uQP9BDghEMOct3nRa79Iq/Vl1 j51A== X-Received: by 10.68.223.225 with SMTP id qx1mr12585118pbc.157.1374162190519; Thu, 18 Jul 2013 08:43:10 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id w8sm11584340pab.12.2013.07.18.08.43.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 08:43:09 -0700 (PDT) Message-ID: <51E80D0B.2000209@vline.me> Date: Thu, 18 Jul 2013 08:43:07 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Harald Alvestrand References: <51E7324A.3090405@vline.me> <51E7A472.3010206@alvestrand.no> In-Reply-To: <51E7A472.3010206@alvestrand.no> Content-Type: multipart/alternative; boundary="------------020204000200030501080602" X-Gm-Message-State: ALoCoQmH1EMNbJGU67mC1pIbGbrW4VAqBSSs+p3Sj6sT583GEsahtWCmW+H2p819dxMdeDY4Hwo7 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:43:21 -0000 This is a multi-part message in MIME format. --------------020204000200030501080602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes, I apologize for not adding avtext as a cc. Regards, Adam On 7/18/13 1:16 AM, Harald Alvestrand wrote: > On 07/18/2013 02:09 AM, Adam Fineberg wrote: >> Hi, >> >> I'm working on WebRTC services and have found that while developing >> services that forward VP8 video streams if we want to take advantage >> of the VP8 temporal scaling we must get the temporal layer >> information from the RTP header which requires us to decrypt the SRTP >> packets. This is undesirable both because the middle-box needs to >> have access to the keys as well as the because of the added overhead >> of the decrypt/encrypt cycle. This draft proposes an RTP header >> extension that will allow us to use the VP8 temporal layer >> information included in the header extension and therefore do >> forwarding without SRTP decryption. Comments welcome. > > Just checking - you named your draft with the -avtext- convention; > this means that you want comments to go to avtext, yes? > > >> >> Regards, >> Adam Fineberg >> fineberg at vline.com >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> Date: Tue, 09 Jul 2013 10:02:05 -0700 >> From: internet-drafts at ietf.org >> To: Adam Fineberg >> >> >> >> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >> has been successfully submitted by Adam Fineberg and posted to the >> IETF repository. >> >> Filename: draft-fineberg-avtext-temporal-layer-ext >> Revision: 00 >> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >> Creation date: 2013-07-08 >> Group: Individual Submission >> Number of pages: 6 >> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >> >> >> Abstract: >> This document defines a mechanism by which packets of Real-Time >> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >> indicate, in an RTP header extension, the temporal layer information >> about the frame encoded in the RTP packet. This information can be >> used in a middlebox performing bandwidth management of streams >> without requiring it to decrypt the streams. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > -- Regards, Adam --------------020204000200030501080602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes, I apologize for not adding avtext as a cc.

Regards,
Adam

On 7/18/13 1:16 AM, Harald Alvestrand wrote:
On 07/18/2013 02:09 AM, Adam Fineberg wrote:
Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Just checking - you named your draft with the -avtext- convention; this means that you want comments to go to avtext, yes?



Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.



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



-- 
Regards,
Adam
--------------020204000200030501080602-- From fineberg@vline.me Thu Jul 18 08:45:46 2013 Return-Path: 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 3806B21E8088 for ; Thu, 18 Jul 2013 08:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 wRJkOOIgJatj for ; Thu, 18 Jul 2013 08:45:41 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id D026E11E8162 for ; Thu, 18 Jul 2013 08:45:41 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl14so3367898pab.34 for ; Thu, 18 Jul 2013 08:45:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=jXUTlsZ9ee1gEnqWulnepTMcYn1XmbOYiddCXXIpaew=; b=NmXXu9oDoC/qcPt8xJ+nSk2JgOVQ92+uOTzFSkw+PGyk8OCEzt9oNLQZi73ahy7bzm lJwMTlIU5NXdRZ93KL6TZpCp+MqVOGpKw9JnyX0BSCNS7OJoS+Vi0yOocDPC7nya+O3s F2lt4QtTOtOZksdvuIZQP0LA+zCt3ASkno3D2yWenh/ZRWTiYz/bQ0+U0e0wc0TKc1l1 EevP44mcXMwQkKWmeaTOEI83veCNoDliTWVkjjmKq+DWOFkWRNL6gkOlR3PCVKoaEkCa N7YkkXLtd8YmWneZZVdvFWlfh53n5hk561OAUaNMmqjHNaYfgOKAB2BixR8ThMZuvCVt k0/Q== X-Received: by 10.66.146.9 with SMTP id sy9mr13993340pab.16.1374162341121; Thu, 18 Jul 2013 08:45:41 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id ai6sm17379482pad.15.2013.07.18.08.45.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 08:45:40 -0700 (PDT) Message-ID: <51E80DA2.4030500@vline.me> Date: Thu, 18 Jul 2013 08:45:38 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bernard Aboba References: <51E7324A.3090405@vline.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080806000200010002090007" X-Gm-Message-State: ALoCoQkmbN2SFLcURL4RiDswGF7vBHI50+deIZ0YkB0JCXpEpCtfke6dt8aDlz9GEIDfp8MwoD7W Cc: avtext@ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:45:46 -0000 This is a multi-part message in MIME format. --------------080806000200010002090007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard, Good question. I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize. If you'd like to help specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: > Since the need is not codec specific (e.g. it arises with any codec > supporting temporal, spatial and quality scalability), why > a VP8-specific RTP extension? > > ------------------------------------------------------------------------ > Date: Wed, 17 Jul 2013 17:09:46 -0700 > From: fineberg@vline.me > To: rtcweb@ietf.org > Subject: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found that while developing > services that forward VP8 video streams if we want to take advantage > of the VP8 temporal scaling we must get the temporal layer information > from the RTP header which requires us to decrypt the SRTP packets. > This is undesirable both because the middle-box needs to have access > to the keys as well as the because of the added overhead of the > decrypt/encrypt cycle. This draft proposes an RTP header extension > that will allow us to use the VP8 temporal layer information included > in the header extension and therefore do forwarding without SRTP > decryption. Comments welcome. > > Regards, > Adam Fineberg > fineberg at vline.com > > -------- Original Message -------- > Subject: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > Date: Tue, 09 Jul 2013 10:02:05 -0700 > From: internet-drafts at ietf.org > > To: Adam Fineberg > > > > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > has been successfully submitted by Adam Fineberg and posted to the > IETF repository. > > Filename: draft-fineberg-avtext-temporal-layer-ext > Revision: 00 > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > Abstract: > This document defines a mechanism by which packets of Real-Time > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > indicate, in an RTP header extension, the temporal layer information > about the frame encoded in the RTP packet. This information can be > used in a middlebox performing bandwidth management of streams > without requiring it to decrypt the streams. > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Regards, Adam --------------080806000200010002090007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

-- 
Regards,
Adam
--------------080806000200010002090007-- From hadriel.kaplan@oracle.com Thu Jul 18 09:25:02 2013 Return-Path: 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 9F92B11E8190 for ; Thu, 18 Jul 2013 09:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 OBPQ4A2tXnoU for ; Thu, 18 Jul 2013 09:24:56 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3A45E11E8147 for ; Thu, 18 Jul 2013 09:24:55 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6IGOQdT018693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Jul 2013 16:24:27 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6IGOPbv020813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jul 2013 16:24:25 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6IGOObi020792; Thu, 18 Jul 2013 16:24:25 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Jul 2013 09:24:24 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 18 Jul 2013 12:24:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9D968BA6-CF33-418F-890C-D2595A2F88E4@oracle.com> References: To: Matthew Kaufman (SKYPE) X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:25:02 -0000 On Jul 17, 2013, at 4:48 PM, Matthew Kaufman (SKYPE) = wrote: >> Given those personal feelings, I didn't much care either way, so long = as a >> decision was made - although I still preferred having SDES to avoid = the early >> media clipping problem. So when I was going to present on this topic = back in >> the Vancouver meeting, my last slide basically said: "If we support = SDES and it >> turns out later we were wrong, we can always rescind it". This was = based on >> the notion that browsers get updated all the time, especially for = security >> issues. >>=20 >> But later it occurred to me that's actually the Achilles' heel of = supporting SDES >> in WebRTC, for those of us wanting to gateway this stuff to SIP. = Imagine if it >> turns out we were wrong, and some expected-or-unexpected = vulnerability is >> exploited against some large WebRTC service provider, and makes the >> news/slashdot. Browser vendors would instantly have new code = removing >> SDES support, and browsers in devices would be updated virtually = overnight - >> some users may take a long time to upgrade their specific browsers on = their >> specific devices - but many of them would do so within days. That = would be >> untenable for a WebRTC service provider.=20 >=20 > I can't imagine such a scenario that couldn't also happen with = DTLS-SRTP, especially DTLS-SRTP + EKT. Yes, I considered that as well - but if there's only one key-exchange = mechanism, and it's the one used between browsers and everyone, then = even the browser vendors wouldn't want to update the browsers in such a = way that it's removed overnight. They'd be braking media interop even = between browsers. For example, assume we only have DTLS-SRTP as MTI and some security = vulnerability is discovered for it, which some new thing called = "ETLS-SRTP" fixes. They couldn't just remove DTLS-SRTP in favor of = ETLS-SRTP overnight; they'd have to support both for some transition = period - a period only constrained by the rate at which most browsers = get updated. After that it could be disabled by default and require the = user to enable, or pop up some warning thingy to approve; and ultimately = removed altogether someday. But with SDES, we're basically asking the browsers to implement = something they don't need to implement for browser-to-browser uses. (in = fact, we'd define it in such a way that SDES wouldn't be used for = browser-to-browser cases) Unless some major service like Skype uses = SDES, browsers vendors have no real market force keeping them supporting = it. The ones involved in this WG have already said they don't consider = the WebRTC-SIP use case very important in the grand scheme of things. > Plus there's lots of counterexamples where major sites have been = compromised in ways that could have been fixed browser-side, and yet = browsers didn't bother to update. Some browsers won't update, for sure - but that's the problem with these = things: it's a lowest-common-denominator model, because having media = work is not an optional feature. If you want to support all (major) = browsers, you need to do what all of them can do. You'd have to support = DTLS-SRTP somehow, if even one of the major browser vendors only do = DTLS-SRTP. Sure you can save some cost by tracking how many people use what = browsers, and deploying for the ratio of DTLS-SRTP vs. SDES you expect, = etc. And that will work for some operators of WebRTC sites/gateways = (though not all). But it still detracts from the arguments I and others = have been making about what the benefits of having SDES would be. > And finally, what makes you think that the browser vendors would do = something like that if the service really was popular? I guess if Google = and Mozilla wanted everyone using Skype to switch to Internet Explorer = they could pull such a stunt, but why? (In a hypothetical future where = IE has webrtc support and Skype supports webrtc-equipped browsers as a = platform for calling, of course) If there's a really popular service using SDES, like let's say Skype, I = would expect the browser vendors to keep SDES support optional with a = configuration thingy; or to keep it by default but only until Skype = switched away from SDES.[1] And I bet Skype would switch away quickly, = if a security vulnerability made the press/slashdot. =20 My point wasn't that it would literally happen in 24 hours - it was more = that such a change is uncontrollable by all the operators of WebRTC = sites/gateways. Skype might be big enough to keep browsers from = removing SDES, but that just moves the problem around: now all the other = WebRTC sites/gateways have to change to using DTLS-SRTP when Skype = changes. Either way, they can't control their own destiny. >> Or if the WG prefers, we could even write a separate doc on what a = web- >> based framework maker should consider supporting/not-supporting. (I = can >> imagine a few other things they might want to offer that a browser = can't) >=20 > They might be able to turn ICE off, even! Yup. That would be #2 on the list of things an app should be able to = do, right after using SDES. (or maybe the priority should even be = swapped) -hadriel [1] having said that, there have been cases where the market power of a = browser overcame the market power of a really popular service - like = Apple's iOS-based Safari's lack of Flash support, with respect to = YouTube service. From Michael.Tuexen@lurchi.franken.de Thu Jul 18 09:48:49 2013 Return-Path: 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 BD09121E8105 for ; Thu, 18 Jul 2013 09:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 lDVEZl4gWQGj for ; Thu, 18 Jul 2013 09:48:49 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 95AB521E8088 for ; Thu, 18 Jul 2013 09:48:48 -0700 (PDT) Received: from [192.168.1.200] (p508F0EA8.dip0.t-ipconnect.de [80.143.14.168]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 27BC61C0C0693; Thu, 18 Jul 2013 18:48:47 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Thu, 18 Jul 2013 18:48:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130715203130.5677.31855.idtracker@ietfa.amsl.com> To: Peter Thatcher X-Mailer: Apple Mail (2.1508) Cc: Randell Jesup , "" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:48:49 -0000 On Jul 18, 2013, at 5:19 PM, Peter Thatcher = wrote: >=20 >=20 >=20 > On Thu, Jul 18, 2013 at 2:11 AM, Michael Tuexen = wrote: > On Jul 16, 2013, at 2:43 AM, Peter Thatcher = wrote: >=20 > > Hey Randell, can you give a short summary of the changes, if any, = that I would or other implementors would need to know about? > Hi Peter, >=20 > using > = http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-jesup-= rtcweb-data-protocol-04.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-rtc= web-data-protocol-00.txt > you see that in addition to clarifications and cleanups >=20 > Oh, now that's a slick tool. Thanks for the link. > =20 > * external negotiation of data channels is described > * the packet format of the DATA_CHANNEL_OPEN message as been changed >=20 > I just wrote the code to serialize and deserialize that message. = Please tell me we're not going to change it again :). I think the format is now pretty good. I don't expect it to change. Best regards Michael > =20 > Both of these changes require code changes. >=20 > Best regards > Michael > > > > > > On Mon, Jul 15, 2013 at 1:31 PM, wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. > > > > Title : WebRTC Data Channel Protocol > > Author(s) : Randell Jesup > > Salvatore Loreto > > Michael Tuexen > > Filename : draft-ietf-rtcweb-data-protocol-00.txt > > Pages : 11 > > Date : 2013-07-15 > > > > Abstract: > > The Web Real-Time Communication (WebRTC) working group is charged = to > > provide protocols to support for direct interactive rich > > communication using audio, video, and data between two peers' = web- > > browsers. This document specifies an actual (minor) protocol for = how > > the JS-layer DataChannel objects provide the data channels = between > > the peers. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 From martin.thomson@gmail.com Thu Jul 18 09:53:52 2013 Return-Path: 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 3B36011E80FD for ; Thu, 18 Jul 2013 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, 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 2qD4DZA+gm1c for ; Thu, 18 Jul 2013 09:53:51 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7950721E8088 for ; Thu, 18 Jul 2013 09:53:50 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so3056659wgh.4 for ; Thu, 18 Jul 2013 09:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j2XOLbZHGYRWI2evhz0jyCmZE6dOh2DhlD6DSFnwv+c=; b=fnT9RKLClb8XJE115J9Lz2ktqGZb2C777dOmWgOzPXU+X9WWQCHXqsaulU87oFdzAF 0SS7Oq7w6obe64EqZNBw/zhRRE6cVKsUADo7kQBBwWmr5n55AWZf5AOWGZk+J/sr8a+C Ycj6DWJrvVlUPrsau8fFJhlWSdni6AEgGky//MrIp3eqQeLVfPS+CCIrvHyw6zN8zEMX ZRRFyEP8yG48TShrM2FE7fFmrWRetZEmuCKtqwZ4/83Ig2FY4zQJDr45aEF8El+rMhmO Ea95C5+S+6TwEBrduUOyNZyzoxeBignaeXJfe8flhYNc94PZjbS4dVpTFcItSB/2siJQ Waxw== MIME-Version: 1.0 X-Received: by 10.180.211.106 with SMTP id nb10mr8804703wic.14.1374166427607; Thu, 18 Jul 2013 09:53:47 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 18 Jul 2013 09:53:47 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> Date: Thu, 18 Jul 2013 09:53:47 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:53:52 -0000 On 18 July 2013 08:12, Peter Thatcher 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 From randell-ietf@jesup.org Thu Jul 18 14:16:48 2013 Return-Path: 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 768E711E8210 for ; Thu, 18 Jul 2013 14:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 45E8tgiF2tEk for ; Thu, 18 Jul 2013 14:16:43 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 72CAE11E8214 for ; Thu, 18 Jul 2013 14:16:37 -0700 (PDT) Received: from pool-108-52-103-189.phlapa.fios.verizon.net ([108.52.103.189]:1540 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UzvYv-000Bp4-Lw; Thu, 18 Jul 2013 16:16:33 -0500 Message-ID: <51E85AFF.9090008@jesup.org> Date: Thu, 18 Jul 2013 17:15:43 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Thatcher References: <20130715203130.5677.31855.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030000000104000300020200" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: none Cc: Randell Jesup , "" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 21:16:48 -0000 This is a multi-part message in MIME format. --------------030000000104000300020200 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/18/2013 11:19 AM, Peter Thatcher wrote: > > using > http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-jesup-rtcweb-data-protocol-04.txt&url2=http://tools.ietf.org/id/draft-ietf-rtcweb-data-protocol-00.txt > you see that in addition to clarifications and cleanups > > > Oh, now that's a slick tool. Thanks for the link. > > * external negotiation of data channels is described > > * the packet format of the DATA_CHANNEL_OPEN message as been changed > > > I just wrote the code to serialize and deserialize that message. > Please tell me we're not going to change it again :). No, that's the last time. :-) That was in response to the "why only 16 bits?" questions I got. We changed that internally quite a while ago. -- Randell Jesup randell-ietf@jesup.org --------------030000000104000300020200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/18/2013 11:19 AM, Peter Thatcher wrote:

using
http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-jesup-rtcweb-data-protocol-04.txt&url2=http://tools.ietf.org/id/draft-ietf-rtcweb-data-protocol-00.txt
you see that in addition to clarifications and cleanups

Oh, now that's a slick tool.  Thanks for the link.
 
* external negotiation of data channels is described
* the packet format of the DATA_CHANNEL_OPEN message as been changed

I just wrote the code to serialize and deserialize that message.  Please tell me we're not going to change it again :).

No, that's the last time.  :-)  That was in response to the "why only 16 bits?" questions I got.  We changed that internally quite a while ago.

-- 
Randell Jesup
randell-ietf@jesup.org
--------------030000000104000300020200-- From csp@csperkins.org Thu Jul 18 14:19:15 2013 Return-Path: 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 63BD821E8099 for ; Thu, 18 Jul 2013 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 6dJ+n5gxfGWu for ; Thu, 18 Jul 2013 14:19:10 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id A6B1D11E8209 for ; Thu, 18 Jul 2013 14:19:10 -0700 (PDT) Received: from [81.187.2.149] (port=40188 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UzvbP-0003IE-Th for rtcweb@ietf.org; Thu, 18 Jul 2013 22:19:09 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Colin Perkins In-Reply-To: <20130715215726.14640.21291.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2013 22:19:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130715215726.14640.21291.idtracker@ietfa.amsl.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1508) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-07.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 21:19:15 -0000 Hi, I submitted an update to the RTCWEB RTP usage draft. This version tries = to address the comments that have been made to the list over the last = couple of months. The changes in this version are as follows: - In Section 4.1, expand discussion of multiple simultaneous SSRC values = in a single RTP session, referencing draft-ietf-avtcore-rtp-multi-stream = and draft-ietf-avtcore-rtp-multi-stream-optimisation. Add a note = suggesting that draft-westerlund-mmusic-max-ssrc might be a useful = addition. - In Section 4.3, expand discussion of RTP payload type assignment, and = briefly explain how the RTP payload type can be used to associate an RTP = media stream with a signalling context (e.g., an SDP "m=3D" line). - In Section 4.3, clarify that this memo does not specify mandatory to = implement codecs or RTP payload formats. Also clarify that any codec = where there is an RTP payload format and SDP offer/answer procedures = defined can be used with WebRTC, provided it is negotiated. - In Section 4.4, clarify that a single RTP session is to be used for = all RTP media streams. Note that there is no consensus to use a = shim-based approach. - In Section 4.8, clarify that implementations MUST be prepared to = accept RTP and RTCP packets using SSRCs that have not been explicitly = signalled. Briefly explain how RTP media streams can be associated with = a signalling context, using either a signalled SSRC or the RTP payload = type. - In Section 5.2.1, clarify that the rapid synchronisation extensions = are in addition to RTCP SR-based synchronisation, and do not replace it. - In Section 6.1, add a reference to RFC 3550 to explain how to do the = RTT calculation from SR/RR packets. - Remove the first paragraph of Section 7.2, since the issue is covered = by the text in the last paragraph of Section 7.1. - Move the remaining content from Section 7.2 to the end of Section 7.4, = where it fits better. - In what was Section 7.4, and is now Section 7.3, add some words about = interoperability between sender- and receiver-driven congestion control. = This issue is not solvable in this draft, since we don't yet have any = standardised congestion control algorithms of either type, however it is = important to note that it needs to be addressed when future congestion = control algorithms are defined. - Rewrite Section 8, on Performance Monitoring, to reflect the = discussion at IETF 86. - Add a note to Section 12.2 about the issue #20 in the RTCWEB issue = tracker - Editorial fixes to Sections 1, 2, 4.2, 4.5, 4.6, 4.7, 5.1, 6, 7, 10, = and 11. - Update list of open issues. The draft contains a list of open issues in Section 15. Also, note that = Sections 11, 12, and Appendix A have yet to be updated, due to running = out of time before the submission deadline. Comments are appreciated.=20 Colin On 15 Jul 2013, at 22:57, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Author(s) : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-07.txt > Pages : 61 > Date : 2013-07-15 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) framework provides support > for direct interactive rich communication using audio, video, text, > collaboration, games, etc. between two peers' web-browsers. This > memo describes the media transport aspects of the WebRTC framework. > It specifies how the Real-time Transport Protocol (RTP) is used in > the WebRTC context, and gives requirements for which RTP features, > profiles, and extensions need to be supported. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From martin.thomson@gmail.com Thu Jul 18 15:39:30 2013 Return-Path: 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 7AEF821E80F7 for ; Thu, 18 Jul 2013 15:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, 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 9OtNGqaHXpT7 for ; Thu, 18 Jul 2013 15:39:30 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CA8E211E821F for ; Thu, 18 Jul 2013 15:39:29 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so3399193wes.19 for ; Thu, 18 Jul 2013 15:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lGYP6cHlc1mNWxTCsVCaNvJQhZ3FCibORlEPihwAfq4=; b=rK/hoViRo3NMhaWBCb7KiyYr2Pr0iROvpuUR4XQorediKSpUN342NJj2lgZ1gr/sDE ZtRq38Fx2vBqfQ/Iul9Cd8GffLtqq6DbST1e6beo/Xka6QJSYy8ba39omv+iJpGPDxgx dFCvOQ5eAJOwU9aY1XLH4L9pl8YVlRmq2jPsFL54b9MOSmiCtmo0qQnXUQ3+Ic6AUIGo CYXpEAyiLC7Zqah1JH1LA/zOjVOt2IPAL0nMUuhSJlxBgQ8I2GJnBr8QDpaGb0F9WySJ LXthR5zEwsaBJ39OpsoFB7nwcA3Ku0Eg13q9be2fffZM/Xwf1FuC92J0QuJLNQawCTCy 2mpQ== MIME-Version: 1.0 X-Received: by 10.180.83.163 with SMTP id r3mr9630404wiy.10.1374187168876; Thu, 18 Jul 2013 15:39:28 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 18 Jul 2013 15:39:28 -0700 (PDT) Date: Thu, 18 Jul 2013 15:39:28 -0700 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] data channel reset X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 22:39:30 -0000 This statement, or something like it, is made in several places in the draft: "Channels are closed by an SCTP reset of the Stream." I assume that this uses the "Outgoing SSN Reset Request Parameter", http://tools.ietf.org/html/rfc6525#section-4.1 Should it say that explicitly? From matthew.kaufman@skype.net Thu Jul 18 15:40:46 2013 Return-Path: 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 ; 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 ; 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 ; 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)" To: Martin Thomson , Peter Thatcher 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: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> , In-Reply-To: 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: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 o= ngoing 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", e= tc. (All useful work that is needed for other types of SDP-using applicatio= ns, 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 th= e WEBRTC specification)=0A= =0A= 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 fr= om 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 spec= ification can possibly be complete. (And note that it isn't sufficient to j= ust 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 specificat= ion.)=0A= =0A= Or, as I've pointed out before, we could define a browser API that is entir= ely independent of SDP, and allow enough control that JavaScript programmer= s can arrange objects and set their parameters such that useful SRTP media = streams can be sent and received, and then they can write whatever JavaScri= pt they want to create the SDP that is getting defined over in MMUSIC and o= ther places, or not use those specs if they so desire.=0A= =0A= Matthew Kaufman=0A= =0A= ________________________________________=0A= From: Martin Thomson [martin.thomson@gmail.com]=0A= Sent: Thursday, July 18, 2013 9:53 AM=0A= To: Peter Thatcher=0A= Cc: Matthew Kaufman (SKYPE); ; public-webrtc@w3.org=0A= Subject: Re: [rtcweb] Summary of Application Developers' opinions of the cu= rrent WebRTC API and SDP as a control surface=0A= =0A= On 18 July 2013 08:12, Peter Thatcher wrote:=0A= > I believe I began paying attention to the mailing lists after you sent ou= t=0A= > theses slides that you didn't present. I'm interested in seeing them, an= d=0A= > while I could dig through archives to find them, if convenient, could you= =0A= > please give me a link to the slides? Thanks.=0A= =0A= It wasn't actually November, it was October, which made this harder to=0A= find than I had expected.=0A= =0A= http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/0148.html=0A= =0A= From matthew.kaufman@skype.net Thu Jul 18 15:42:03 2013 Return-Path: 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 D18FD11E81E3 for ; Thu, 18 Jul 2013 15:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hrs4tGt+pkbi for ; Thu, 18 Jul 2013 15:41:58 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5C211E8204 for ; Thu, 18 Jul 2013 15:41:54 -0700 (PDT) Received: from mail31-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Jul 2013 22:41:53 +0000 Received: from mail31-va3 (localhost [127.0.0.1]) by mail31-va3-R.bigfish.com (Postfix) with ESMTP id 795B8602C1; Thu, 18 Jul 2013 22:41:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zz9371Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h1de096h8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail31-va3: 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=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail31-va3 (localhost.localdomain [127.0.0.1]) by mail31-va3 (MessageSwitch) id 1374187312211674_351; Thu, 18 Jul 2013 22:41:52 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.243]) by mail31-va3.bigfish.com (Postfix) with ESMTP id 2DC4D36005E; Thu, 18 Jul 2013 22:41:52 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 18 Jul 2013 22:41:52 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Thu, 18 Jul 2013 22:40:59 +0000 From: "Matthew Kaufman (SKYPE)" To: Martin Thomson , "rtcweb@ietf.org" Thread-Topic: [rtcweb] data channel reset Thread-Index: AQHOhAev2XlnXDUyeEypQSr01Z6yC5lrB5RR Date: Thu, 18 Jul 2013 22:40:59 +0000 Message-ID: References: In-Reply-To: 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 Subject: Re: [rtcweb] data channel reset X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 22:42:03 -0000 Only if you think that RTCWEB should be using SCTP, I suppose.=0A= =0A= Matthew Kaufman=0A= =0A= ________________________________________=0A= From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Martin= Thomson [martin.thomson@gmail.com]=0A= Sent: Thursday, July 18, 2013 3:39 PM=0A= To: rtcweb@ietf.org=0A= Subject: [rtcweb] data channel reset=0A= =0A= This statement, or something like it, is made in several places in the draf= t:=0A= =0A= "Channels are closed by an SCTP reset of the Stream."=0A= =0A= I assume that this uses the "Outgoing SSN Reset Request Parameter",=0A= http://tools.ietf.org/html/rfc6525#section-4.1=0A= =0A= Should it say that explicitly?=0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb=0A= =0A= From silviapfeiffer1@gmail.com Thu Jul 18 17:47:09 2013 Return-Path: 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 7114D11E8165 for ; Thu, 18 Jul 2013 17:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 hZEplfQc93xQ for ; Thu, 18 Jul 2013 17:47:09 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id EC13311E815A for ; Thu, 18 Jul 2013 17:47:08 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id v19so4452241obq.7 for ; Thu, 18 Jul 2013 17:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z9FIzvunIuW7F9KA2eb6CwJ1uqz2Gzk1PguV7fn9jZE=; b=YcxDYqRlwCtjfEeBKVC3+0gxvh8RJIubX/2OEw6GpzBkaw1d96ItuAgtFmYjDfqeFh 97/yCDFKQAsyUU63B/+Jbn8uQw9+LzHrJ6DUfbpUvKeVgYYbT+ZHtBbjBczVTPSswwt5 nW66aJ1ZLsiaUlSDvcGwcqOHEVfsEWN/YJLVoUqSi/Wjw9xv9fI8VJ9xj3gJqlyIvuJV DHfEeEB7CJa35ePx1tuUIwYoxeZ0Y3QuUXuZm1gtSeZ/U7tIS3mdoeIUkkX7nvHDTrh/ Qb0NvvaIUjOqdgYwZlP0mW3xvNDgWLZcKP+o+MN3IpVWEBPWkn3sQ5jlXXlpmrn1asO9 IEuw== X-Received: by 10.60.135.167 with SMTP id pt7mr16025864oeb.59.1374194828525; Thu, 18 Jul 2013 17:47:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.173.106 with HTTP; Thu, 18 Jul 2013 17:46:48 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> From: Silvia Pfeiffer Date: Fri, 19 Jul 2013 10:46:48 +1000 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 00:47:09 -0000 On Fri, Jul 19, 2013 at 2:53 AM, Martin Thomson wrote: > On 18 July 2013 08:12, Peter Thatcher 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. From bernard_aboba@hotmail.com Thu Jul 18 19:40:13 2013 Return-Path: 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 5772C21E815C; Thu, 18 Jul 2013 19:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 c4kIuI9nv6c2; Thu, 18 Jul 2013 19:40:08 -0700 (PDT) Received: from blu0-omc4-s35.blu0.hotmail.com (blu0-omc4-s35.blu0.hotmail.com [65.55.111.174]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8721E813A; Thu, 18 Jul 2013 19:40:08 -0700 (PDT) Received: from BLU169-W107 ([65.55.111.137]) by blu0-omc4-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 19:40:07 -0700 X-TMN: [8StdPs56VaXZ0flKiKzTGvdAqo3Db3STgwAlm+JlLkU=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_e40724f7-758d-4c47-8861-18af1b356bd4_" From: Bernard Aboba To: Adam Fineberg Date: Thu, 18 Jul 2013 19:40:07 -0700 Importance: Normal In-Reply-To: <51E80DA2.4030500@vline.me> References: <51E7324A.3090405@vline.me> , <51E80DA2.4030500@vline.me> MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jul 2013 02:40:07.0645 (UTC) FILETIME=[47FA88D0:01CE8429] Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 02:40:13 -0000 --_e40724f7-758d-4c47-8861-18af1b356bd4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it may be possible to generalize this. For example=2C for H.264/SV= C which can support temporal=2C spatial and quality scalability=2C you woul= d need the quality_id and dependency_id in addition to the temporal_id (wha= t you call the temporal layer index). =20 Date: Thu=2C 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org=3B avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt =0A= =0A= =0A= =0A= =0A= Bernard=2C =0A= =20 =0A= Good question. I'm not familiar enough with the parameter=0A= requirements of all other scalable codecs to be able to generalize. =0A= If you'd like to help specify them=2C I'd be fine revising the draft=0A= to generalize. =0A= =20 =0A= Regards=2C =0A= Adam =0A= =20 =0A= On 7/17/13 8:26 PM=2C Bernard Aboba=0A= wrote: =0A= =0A= =0A= =0A= Since the need is not codec specific (e.g. it=0A= arises with any codec supporting temporal=2C spatial and quality=0A= scalability)=2C why=20 =0A= a VP8-specific RTP extension?=20 =0A= =20 =0A= =0A= Date: Wed=2C 17 Jul 2013 17:09:46 -0700 =0A= From: fineberg@vline.me =0A= To: rtcweb@ietf.org =0A= Subject: [rtcweb] Fwd: New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt =0A= =20 =0A= Hi=2C=0A= =0A= I'm working on WebRTC=0A= services and have found that while developing services that=0A= forward VP8 video streams if we want to take advantage of=0A= the VP8 temporal scaling we must get the temporal layer=0A= information from the RTP header which requires us to decrypt=0A= the SRTP packets. This is undesirable both because the=0A= middle-box needs to have access to the keys as well as the=0A= because of the added overhead of the decrypt/encrypt cycle.=0A= This draft proposes an RTP header extension that will allow=0A= us to use the VP8 temporal layer information included in the=0A= header extension and therefore do forwarding without SRTP=0A= decryption. Comments welcome.=0A= =0A= Regards=2C=0A= Adam Fineberg=0A= fineberg=0A= at vline.com =0A= =20 =0A= -------- Original Message --------=0A= =0A= =0A= =0A= Subject:=0A= New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt=0A= =0A= =0A= Date:=0A= Tue=2C 09 Jul 2013 10:02:05 -0700=0A= =0A= =0A= From:=0A= internet-drafts at ietf.org=0A= =0A= =0A= To:=0A= Adam Fineberg =0A= =0A= =0A= =0A= =20 =0A= =20 =0A= A new version of I-D=2C draft-fineberg-avtext-temporal-layer-ex= t-00.txt=0A= has been successfully submitted by Adam Fineberg and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-fineberg-avtext-temporal-layer-ext=0A= Revision: 00=0A= Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp= oral Layer Information=0A= Creation date: 2013-07-08=0A= Group: Individual Submission=0A= Number of pages: 6=0A= URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt=0A= Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext=0A= Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00=0A= =0A= =0A= Abstract:=0A= This document defines a mechanism by which packets of Real-Time=0A= Tranport Protocol (RTP) video streams encoded with the VP8 codec can=0A= indicate=2C in an RTP header extension=2C the temporal layer information= =0A= about the frame encoded in the RTP packet. This information can be=0A= used in a middlebox performing bandwidth management of streams=0A= without requiring it to decrypt the streams.=0A= =0A= =0A= =20 =0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb=0A= =0A= =0A= =20 =0A= -- =0A= Regards=2C=0A= Adam = --_e40724f7-758d-4c47-8861-18af1b356bd4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think it may be possible to ge= neralize this. =3B For example=2C for H.264/SVC which can support tempo= ral=2C spatial and quality scalability=2C you would need the quality_id and= dependency_id in addition to the temporal_id (what you call the temporal l= ayer index).  =3B =3B

Date: Th= u=2C 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_a= boba@hotmail.com
CC: rtcweb@ietf.org=3B avtext@ietf.org
Subject: Re: = [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-l= ayer-ext-00.txt

=0A= =0A= =0A= =0A= =0A= Bernard=2C
=0A=
=0A= Good question. =3B I'm not familiar enough with the parameter=0A= requirements of all other scalable codecs to be able to generalize.&nbs= p=3B=0A= If you'd like to help specify them=2C I'd be fine revising the draft=0A= to generalize.
=0A=
=0A= Regards=2C
=0A= Adam
=0A=
=0A=
On 7/17/13 8:26 PM=2C Bernard Aboba= =0A= wrote:
=0A=
=0A=
= =0A= =0A=
Since the need is not codec specific (e.g. it=0A= arises with any codec supporting temporal=2C spatial and quality=0A= scalability)=2C why
=0A=  =3Ba VP8-specific RTP extension?
=0A=  =3B
=0A=
=0A=
Date: Wed=2C 17 Jul 2013 17:09:46 -070= 0
=0A= From: fineberg@vline.me
=0A= To: rtcweb@ietf.org
=0A= Subject: [rtcweb] Fwd: New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt
=0A=
=0A= Hi=2C
=0A=
=0A= I'm working on WebRTC=0A= services and have found that while developing services that=0A= forward VP8 video streams if we want to take advantage of=0A= the VP8 temporal scaling we must get the temporal layer=0A= information from the RTP header which requires us to decrypt=0A= the SRTP packets. This is undesirable both because the=0A= middle-box needs to have access to the keys as well as the=0A= because of the added overhead of the decrypt/encrypt cycle.=0A= This draft proposes an RTP header extension that will allow=0A= us to use the VP8 temporal layer information included in the=0A= header extension and therefore do forwarding without SRTP=0A= decryption. Comments welcome.
=0A=
=0A= Regards=2C
=0A= Adam Fineberg
=0A=
fineberg=0A= at vline.com
=0A=
=0A= -------- Original Message --------=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
Subject:New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt
Date:Tue=2C 09 Jul 2013 10:02:05 -0700
From:internet-drafts at iet= f.org
To:Adam Fineberg =3B<=3Bfineberg at vline.com>=3B=
=0A=
=0A=
=0A= 
A new version of I-D=2C draft-fineberg-avtext-temporal-=
layer-ext-00.txt=0A=
has been successfully submitted by Adam Fineberg and posted to the=0A=
IETF repository.=0A=
=0A=
Filename:	 draft-fineberg-avtext-temporal-layer-ext=0A=
Revision:	 00=0A=
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information=0A=
Creation date:	 2013-07-08=0A=
Group:		 Individual Submission=0A=
Number of pages: 6=0A=
URL:             http://www.ietf.org/internet-drafts/draft-=
fineberg-avtext-temporal-layer-ext-00.txt=0A=
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext=
-temporal-layer-ext=0A=
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-tempor=
al-layer-ext-00=0A=
=0A=
=0A=
Abstract:=0A=
   This document defines a mechanism by which packets of Real-Time=0A=
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can=0A=
   indicate=2C in an RTP header extension=2C the temporal layer information=
=0A=
   about the frame encoded in the RTP packet.  This information can be=0A=
   used in a middlebox performing bandwidth management of streams=0A=
   without requiring it to decrypt the streams.=0A=
=0A=
=0A=
=0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/l= istinfo/rtcweb
=0A=
=0A=
=0A=
=0A= 
-- =0A=
Regards=2C=0A=
Adam
= --_e40724f7-758d-4c47-8861-18af1b356bd4_-- From juberti@google.com Thu Jul 18 19:40:43 2013 Return-Path: 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 1326D21E8138 for ; Thu, 18 Jul 2013 19:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.269, 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 PzeL2qoeihiS for ; Thu, 18 Jul 2013 19:40:42 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0B21A21E815C for ; Thu, 18 Jul 2013 19:40:41 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so7339036wib.0 for ; Thu, 18 Jul 2013 19:40:41 -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=/ydh9Pb9ZHypehOC02JgeAzckziv5pTI/NlMjd3aT3A=; b=lRucdcxoVr9j5LC8n3RJPJCGS/sMxcO1GqU4VdtZClJEsk7dZpWztiqQ3q2tCEkNVX iunPR0Lx/dcfcRtDQcJJKvNclqHN2LF4ixGV9Z3lrDIoXnMNOwjnr0yhliWGUdYKvCXM 9EqMIrH8jU7YNEAS50wPcbmJnr1iMfCMBKQMNDFx2amC+bRQfoN2ov6mf7ukdeQ/gDpH a8s2fP28wX4LERKo8ozp0EHN/REnBlcRHPG84HcV+GIv81Wxad8zZJhYlYIStc4fIIvk 1xysfGseErJJS1VCKp8AO/Q0C77GBZuo8QH6HCbkhlkZwg6kyy3KRTdJIGsqDsNEPNnB d7yg== 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=/ydh9Pb9ZHypehOC02JgeAzckziv5pTI/NlMjd3aT3A=; b=pl6gi5vZBAkwm0hqWEBgjBppjYSf9NBdBhsW6wqmzyFhCTvYEMdE3BiisB93IyAeD4 +tN8rxw7kdFS9xtBwKwxXlhEk127yzpt+20WRSuJetMSYPJNQ/AnYKoQZ7umg0bxB0Hr TT7EcUeTCCaEJss4QmXNLI/YC/WG6gM1h86V7rRNaBTTNBukyPk2uNZYn1OhbsyUOsr5 3JpV0/Dvplr/qpTkCKmHEpb8oAhUAUDSR4I7mS1AkhKymSlNba86kU4sBjJjFJWA4ebC KnqLxtQvDQm+PG/JzfOPISjH0CpjtfM5PxLQzOTW45uHCVoAMiANv4Q1cSA5G6do0xE2 FtQQ== X-Received: by 10.180.107.167 with SMTP id hd7mr9851872wib.33.1374201641001; Thu, 18 Jul 2013 19:40:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Thu, 18 Jul 2013 19:40:20 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> From: Justin Uberti Date: Thu, 18 Jul 2013 22:40:20 -0400 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=e89a8f2353a7a98cad04e1d440ea X-Gm-Message-State: ALoCoQlNpozQp7MV6XYfvKTkpET9XfqlVQhVHNmbFZmuil72JY9BtMnBf7nDmgcOxN7+Cq7s+4ONENN21sOw4AvSPvaVhqdC7vsiIdis0Gh5r895HnzCk+C74U/+D3XQxamIHv3CyblDNrI+8OdYBFTxAW/RdLIvg3Tv/ARSI3s3P4vnEbQL9zc3FUSEHzHJ7NuutKLmJHcE Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 02:40:43 -0000 --e89a8f2353a7a98cad04e1d440ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, for the past 6+ months we haven't been able to agree on exactly how a MediaStreamTrack should be represented in SDP, so it would have been premature to try to write this stuff down. That said, I agree this stuff needs to be fully defined, so that applications can get predictable behavior. I also agree it will be a large undertaking. On Tue, Jul 16, 2013 at 8:30 PM, Bernard Aboba w= rote: > I would agree. Just pointing out that this issue was raised in December > 2012, and it is now 6+ months later with little progress and more > disgruntlement. So if there is motivation to fix this it probably would > have manifested itself by now. > > On Jul 16, 2013, at 5:27 PM, "Silvia Pfeiffer" > wrote: > > > The whole point of standardisation at the W3C is for browser to agree > > on the knobs. So, I do think it's a valuable effort. > > Cheers, > > Silvia. > > > > > > On Wed, Jul 17, 2013 at 10:15 AM, Bernard Aboba > > wrote: > >> The problem was that we never defined what mangling browsers had to > support. Given all the SDP specs that is actually a huge work item. And > creating APIs to avoid mangling isn't actually that much simpler. What > knobs do you provide and which ones do you ignore? Browsers might not agr= ee > on those either. > >> > >> On Jul 8, 2013, at 1:37 PM, "Stefan H=C3=A5kansson LK" < > stefan.lk.hakansson@ericsson.com> wrote: > >> > >>> On 7/8/13 5:22 PM, Roman Shpount wrote: > >>> > >>>> So, was there ever a consensus that "developers MUST NOT > >>>> touch SDP"? > >>> > >>> No, developers are free to touch the SDP (and probably must in certai= n > >>> cases). > >>> > >>>> > >>>> _____________ > >>>> Roman Shpount > >>> > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --e89a8f2353a7a98cad04e1d440ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, for the past 6+ months we haven't been able to a= gree on exactly how a MediaStreamTrack should be represented in SDP, so it = would have been premature to try to write this stuff down.

That said, I agree this stuff needs to be fully defined, so that applicatio= ns can get predictable behavior. I also agree it will be a large undertakin= g.


On Tue= , Jul 16, 2013 at 8:30 PM, Bernard Aboba <bernard_aboba@hotmail.co= m> wrote:
I would agree. Just pointing out that this i= ssue was raised in December 2012, and it is now 6+ months later with little= progress and more disgruntlement. So if there is motivation to fix this it= probably would have manifested itself by now.

On Jul 16, 2013, at 5:27 PM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:

> The whole point of standardisation at the W3C is for browser to agree<= br> > on the knobs. So, I do think it's a valuable effort.
> Cheers,
> Silvia.
>
>
> On Wed, Jul 17, 2013 at 10:15 AM, Bernard Aboba
> <bernard_aboba@hotmail= .com> wrote:
>> The problem was that we never defined what mangling browsers had t= o support. Given all the SDP specs that is actually a huge work item. And c= reating APIs to avoid mangling isn't actually that much simpler. What k= nobs do you provide and which ones do you ignore? Browsers might not agree = on those either.
>>
>> On Jul 8, 2013, at 1:37 PM, "Stefan H=C3=A5kansson LK" &= lt;stefan.lk.hakansson@= ericsson.com> wrote:
>>
>>> On 7/8/13 5:22 PM, Roman Shpount wrote:
>>>
>>>> So, was there ever a consensus that "developers MUST = NOT
>>>> touch SDP"?
>>>
>>> No, developers are free to touch the SDP (and probably must in= certain
>>> cases).
>>>
>>>>
>>>> _____________
>>>> Roman Shpount
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--e89a8f2353a7a98cad04e1d440ea-- From fineberg@vline.me Thu Jul 18 20:34:21 2013 Return-Path: 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 4E73611E827B; Thu, 18 Jul 2013 20:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 8RNqKuCaqEac; Thu, 18 Jul 2013 20:34:20 -0700 (PDT) Received: from cat2.kjsl.com (cat2.kjsl.com [IPv6:2001:1868:2001::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBDD11E8278; Thu, 18 Jul 2013 20:34:20 -0700 (PDT) Received: from Adam-Finebergs-MacBook-Pro-2.local (75-25-130-225.lightspeed.sjcpca.sbcglobal.net [75.25.130.225]) (Authenticated sender: fineberg) by cat2.kjsl.com (Postfix) with ESMTP id AE5E712550A; Thu, 18 Jul 2013 23:34:17 -0400 (EDT) Message-ID: <51E8B3B8.3090502@vline.me> Date: Thu, 18 Jul 2013 20:34:16 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bernard Aboba References: <51E7324A.3090405@vline.me> , <51E80DA2.4030500@vline.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050600000506060503030109" Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 03:34:21 -0000 This is a multi-part message in MIME format. --------------050600000506060503030109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard, Are there other codecs you are thinking should be supported? If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: > I think it may be possible to generalize this. For example, for > H.264/SVC which can support temporal, spatial and quality scalability, > you would need the quality_id and dependency_id in addition to the > temporal_id (what you call the temporal layer index). > > ------------------------------------------------------------------------ > Date: Thu, 18 Jul 2013 08:45:38 -0700 > From: fineberg@vline.me > To: bernard_aboba@hotmail.com > CC: rtcweb@ietf.org; avtext@ietf.org > Subject: Re: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Bernard, > > Good question. I'm not familiar enough with the parameter > requirements of all other scalable codecs to be able to generalize. > If you'd like to help specify them, I'd be fine revising the draft to > generalize. > > Regards, > Adam > > On 7/17/13 8:26 PM, Bernard Aboba wrote: > > Since the need is not codec specific (e.g. it arises with any > codec supporting temporal, spatial and quality scalability), why > a VP8-specific RTP extension? > > ------------------------------------------------------------------------ > Date: Wed, 17 Jul 2013 17:09:46 -0700 > From: fineberg@vline.me > To: rtcweb@ietf.org > Subject: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found that while > developing services that forward VP8 video streams if we want to > take advantage of the VP8 temporal scaling we must get the > temporal layer information from the RTP header which requires us > to decrypt the SRTP packets. This is undesirable both because the > middle-box needs to have access to the keys as well as the because > of the added overhead of the decrypt/encrypt cycle. This draft > proposes an RTP header extension that will allow us to use the VP8 > temporal layer information included in the header extension and > therefore do forwarding without SRTP decryption. Comments welcome. > > Regards, > Adam Fineberg > fineberg at vline.com > > -------- Original Message -------- > Subject: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > Date: Tue, 09 Jul 2013 10:02:05 -0700 > From: internet-drafts at ietf.org > > To: Adam Fineberg > > > > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > has been successfully submitted by Adam Fineberg and posted to the > IETF repository. > > Filename: draft-fineberg-avtext-temporal-layer-ext > Revision: 00 > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > Abstract: > This document defines a mechanism by which packets of Real-Time > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > indicate, in an RTP header extension, the temporal layer information > about the frame encoded in the RTP packet. This information can be > used in a middlebox performing bandwidth management of streams > without requiring it to decrypt the streams. > > > _______________________________________________ rtcweb mailing > list rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Regards, > Adam --------------050600000506060503030109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

-- 
Regards,
Adam

--------------050600000506060503030109-- From denglingli@chinamobile.com Thu Jul 18 22:34:04 2013 Return-Path: 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 848D611E829D for ; Thu, 18 Jul 2013 22:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152] 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 HyLpUNTwogmu for ; Thu, 18 Jul 2013 22:34:00 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 48EAF11E8297 for ; Thu, 18 Jul 2013 22:33:54 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee151e8cf7b89c-3589c; Fri, 19 Jul 2013 13:32:43 +0800 (CST) X-RM-TRANSID: 2ee151e8cf7b89c-3589c Received: from cmccPC (unknown[10.2.43.200]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee251e8cf78b36-6233b; Fri, 19 Jul 2013 13:32:43 +0800 (CST) X-RM-TRANSID: 2ee251e8cf78b36-6233b From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'Paul Coverdale'" , "'Hutton, Andrew'" , "'Bogineni, Kalyani'" , "'Bo Burman'" , References: <20130716170223.B5DD911E80D7@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF1164B89C@MCHP04MSX.global-ad.net> In-Reply-To: Date: Fri, 19 Jul 2013 13:33:42 +0800 Message-ID: <00b801ce8441$88198e80$984cab80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6BN11IugiIgzm2TXug3PomYB8N3ABDXdRAACEuDYAAOgsjMAAf0RCw Content-Language: zh-cn Subject: [rtcweb] =?utf-8?b?562U5aSNOiAgU29tZSB0aG91Z2h0cyBvbiBvcHRpb25h?= =?utf-8?q?l_audio_codecs?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 05:34:04 -0000 We also support this proposal. In particular, I think it makes sense to allow the codec choice be = possibly delegated to individual web developers making use of WebRTC = functionality. Therefore, it would be better for them to be informed of available = options and make the decision accordingly. While it is not realistic to assume that a browser could always = implement a best choice for every potential setting, to include other = available codec in the offer would open the door to a win-win outcome. BR Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: rtcweb-bounces@ietf.org = [mailto:rtcweb-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Paul Coverdale =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=8818=E6=97=A5 = 20:25 =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Hutton, Andrew'; 'Bogineni, Kalyani'; 'Bo = Burman'; rtcweb@ietf.org =E4=B8=BB=E9=A2=98: Re: [rtcweb] Some thoughts on optional audio codecs Yes, this text has been around for a while. I also support it. ...Paul >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >Of Hutton, Andrew >Sent: Wednesday, July 17, 2013 4:46 AM >To: Bogineni, Kalyani; 'Bo Burman'; rtcweb@ietf.org >Subject: Re: [rtcweb] Some thoughts on optional audio codecs > >We appear to have been around this loop a number of times the text >suggested here is exactly what was suggested by Andrew Allen back in >January and I for one supported it them and still do - See >http://www.ietf.org/mail-archive/web/rtcweb/current/msg06121.html. > >Not sure there was a definitive conclusion to that particular consensus >call. > >Andy > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Bogineni, Kalyani >> Sent: 16 July 2013 18:02 >> To: 'Bo Burman'; rtcweb@ietf.org >> Cc: Bogineni, Kalyani >> Subject: Re: [rtcweb] Some thoughts on optional audio codecs >> >> We support the following wording proposal from Bo Burman. >> >> "If other suitable audio codecs are available to the browser to use, >> it is recommended that they are also included in the offer in order = to >> maximize the possibility to establish the session without the need = for >> audio transcoding". >> >> Regards, >> Kalyani Bogineni >> Verizon >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Bo Burman >> Sent: Monday, July 15, 2013 11:15 AM >> To: rtcweb@ietf.org >> Subject: [rtcweb] Some thoughts on optional audio codecs >> >> Regarding the previous discussion on optional audio codecs in the >> (currently expired) draft on RTCWEB audio codecs >> (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/): >> >> I think most parties involved in WebRTC work, myself included, hope >> and believe that it will be ubiquitous and easy to include real-time >> media conversation functionality in nearly any web context. Since it >> will be that easy, it can be expected that most web developers need >> not be, and thus will not be, media specialists or very knowledgeable >about codecs. >> >> The definition of RTCWEB MTI codecs ensures that communication is >> possible since at least one codec will always be found, but it is not >> possible to claim the resulting communication to be optimum for every >> possible context. >> >> Even if WebRTC will be close to ubiquitous, there will for quite some >> time likely be a desire to reach real-time media domains and devices >> that were not originally designed for and thus are not optimized for >> use with WebRTC. A communication device that is not designed solely >> for WebRTC use will likely include functionality and codecs also for >> its "native" domain. >> >> Any added cost of not being able to use existing "native" codecs will >> vary both in amount and where the cost has to be taken. Eliminating = it >> is indeed an optimization, but the total cost savings may still be >> significant. >> >> With the current design and to my understanding, it will be the >> browser vendor's choice to add optional codecs, including any = "native" >> domain codecs. The choice may possibly be delegated to individual = web >> developers making use of WebRTC functionality. A browser vendor will >> arguably have to know each target platform to some extent, but it can >> hardly be assumed that a web developer knows the capabilities of all >> devices that will use the WebRTC-enabled site unless the browser can >> provide the needed information. There is a risk that "native" codecs >> in devices are not well handled, unless the motivations and methods = to >> make use of them are better specified. >> >> While any audio codecs besides the MTI ones are clearly optional, I >> believe the suggested text addition on optional audio codecs to the >> RTCWEB audio draft in Ticket #12 >> (http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/12#) to be too = brief >> considering the above. >> >> In that draft, I would prefer something more in line with: >> >> "If other suitable audio codecs are available to the browser to use, >> it is recommended that they are also included in the offer in order = to >> maximize the possibility to establish the session without the need = for >> audio transcoding". >> >> Assuming that the browser vendor (or web developer) is sufficiently >> concerned with codecs to read the audio codecs draft (or the >> corresponding RFC to-be), the above text may, as a start, give some >> added guidance why non-MTI codecs may be desirable to consider in >> addition to the MTI ones. >> >> Cheers, >> Bo >> >> Multimedia Technologies >> Ericsson Research >> F=C3=A4r=C3=B6gatan 6 >> SE-164 80, Kista, Sweden >> www.ericsson.com >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Thu Jul 18 22:56:30 2013 Return-Path: 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 C5ACB11E82A3; Thu, 18 Jul 2013 22:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.85 X-Spam-Level: X-Spam-Status: No, score=-101.85 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 GqkJWjeU5Nrh; Thu, 18 Jul 2013 22:56:20 -0700 (PDT) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDAE11E829E; Thu, 18 Jul 2013 22:56:17 -0700 (PDT) Received: from BLU401-EAS75 ([65.55.116.72]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Jul 2013 22:56:16 -0700 X-TMN: [XL0vYhv/qdKDyNQZ7Du3jkvRaw85Bc66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-C7668BC4-5989-40CD-888A-D7A5292B2C95" Content-Transfer-Encoding: 7bit References: <51E7324A.3090405@vline.me> <51E80DA2.4030500@vline.me> <51E8B3B8.3090502@vline.me> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <51E8B3B8.3090502@vline.me> Date: Thu, 18 Jul 2013 22:56:12 -0700 To: Adam Fineberg X-OriginalArrivalTime: 19 Jul 2013 05:56:16.0271 (UTC) FILETIME=[AEA059F0:01CE8444] Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 05:56:30 -0000 --Apple-Mail-C7668BC4-5989-40CD-888A-D7A5292B2C95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" wrote: > Bernard, >=20 > Are there other codecs you are thinking should be supported? If it's gene= ralized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generaliz= ed header. >=20 > Regards, > Adam >=20 > On 7/18/13 7:40 PM, Bernard Aboba wrote: >> I think it may be possible to generalize this. For example, for H.264/SV= C which can support temporal, spatial and quality scalability, you would nee= d the quality_id and dependency_id in addition to the temporal_id (what you c= all the temporal layer index). =20 >>=20 >> Date: Thu, 18 Jul 2013 08:45:38 -0700 >> From: fineberg@vline.me >> To: bernard_aboba@hotmail.com >> CC: rtcweb@ietf.org; avtext@ietf.org >> Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-av= text-temporal-layer-ext-00.txt >>=20 >> Bernard, >>=20 >> Good question. I'm not familiar enough with the parameter requirements o= f all other scalable codecs to be able to generalize. If you'd like to help= specify them, I'd be fine revising the draft to generalize. >>=20 >> Regards, >> Adam >>=20 >> On 7/17/13 8:26 PM, Bernard Aboba wrote: >> Since the need is not codec specific (e.g. it arises with any codec suppo= rting temporal, spatial and quality scalability), why=20 >> a VP8-specific RTP extension?=20 >> =20 >> Date: Wed, 17 Jul 2013 17:09:46 -0700 >> From: fineberg@vline.me >> To: rtcweb@ietf.org >> Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext= -temporal-layer-ext-00.txt >>=20 >> Hi, >>=20 >> I'm working on WebRTC services and have found that while developing servi= ces that forward VP8 video streams if we want to take advantage of the VP8 t= emporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both b= ecause the middle-box needs to have access to the keys as well as the becaus= e of the added overhead of the decrypt/encrypt cycle. This draft proposes an= RTP header extension that will allow us to use the VP8 temporal layer infor= mation included in the header extension and therefore do forwarding without S= RTP decryption. Comments welcome. >>=20 >> Regards, >> Adam Fineberg >> fineberg at vline.com >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for draft-fineberg-avtext-temporal= -layer-ext-00.txt >> Date: Tue, 09 Jul 2013 10:02:05 -0700 >> From: internet-drafts at ietf.org >> To: Adam Fineberg >>=20 >> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >> has been successfully submitted by Adam Fineberg and posted to the >> IETF repository. >>=20 >> Filename: draft-fineberg-avtext-temporal-layer-ext >> Revision: 00 >> Title: A Real-Time Transport Protocol (RTP) Header Extens= ion for VP8 Temporal Layer Information >> Creation date: 2013-07-08 >> Group: Individual Submission >> Number of pages: 6 >> URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtex= t-temporal-layer-ext-00.txt >> Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-te= mporal-layer-ext >> Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-tempora= l-layer-ext-00 >>=20 >>=20 >> Abstract: >> This document defines a mechanism by which packets of Real-Time >> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >> indicate, in an RTP header extension, the temporal layer information >> about the frame encoded in the RTP packet. This information can be >> used in a middlebox performing bandwidth management of streams >> without requiring it to decrypt the streams. >>=20 >> _______________________________________________ rtcweb mailing list rtcwe= b@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> --=20 >> Regards, >> Adam >=20 --Apple-Mail-C7668BC4-5989-40CD-888A-D7A5292B2C95 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

-- 
Regards,
Adam

--Apple-Mail-C7668BC4-5989-40CD-888A-D7A5292B2C95-- From stefan.lk.hakansson@ericsson.com Fri Jul 19 03:32:17 2013 Return-Path: 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 C568221E80AA for ; Fri, 19 Jul 2013 03:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_00=-2.599, 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 zPjWj7EJVtiV for ; Fri, 19 Jul 2013 03:32:12 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3D721E8095 for ; Fri, 19 Jul 2013 03:32:11 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-cb-51e915aa5ae3 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 27.20.11907.AA519E15; Fri, 19 Jul 2013 12:32:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 12:32:10 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "Matthew Kaufman (SKYPE)" Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOg8lDQU4UZHPk70iYDIx2uADXhg== Date: Fri, 19 Jul 2013 10:32:09 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C31A9AA@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> , Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvre5q0ZeBBvOW8lpcO/OP0WLGrbMs FteWv2a16P24hNFi7b92dgdWj52z7rJ7LNhU6rFkyU8mj1sPJrF5HJ23nzWANYrLJiU1J7Ms tUjfLoEro/n9dNaCYyIVu188Z21g7BHsYuTkkBAwkTj67hIzhC0mceHeejYQW0jgKKPE1bXK XYxcQPYiRonrezaDFbEJBEps3bcArEhEwFKi+9kbdpAiZoF1jBIXm3azgySEBaoklh8+BmRz ABVVSyzpL4eo15OYeqMHbA6LgKrE+81LWEBsXgFfif139zFBLHvPLtG7/S3YHEagi76fWsME YjMLiEvcejKfCeJSAYkle85DXS0q8fLxP1YIW0micckTVoh6PYkbU6ewQdjaEssWvmaGWCYo cXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGLkKE4tTspNNzLYxAiMpINbflvsYLz81+YQozQH i5I47xa9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFn//HRv5Hgi2qtxf3XU1dj8R9yl PZZ7bf8+8M7Z/1M/szE2yWnW/XJLwSPOc59dZ+vdYFSyhsF37oM1ay7JfTdrmuZ1+oDDgjKJ yfGtu1aK7Xj+kzX9eYVw8yez8sNBsgcsdt6etDpb5MqdjqXLZGTPdhaxvf7evYjlcIrbmYsm Grs/Z9v8PKnEUpyRaKjFXFScCABjF8E6cgIAAA== Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 10:32:17 -0000 On 7/19/13 12:40 AM, Matthew Kaufman (SKYPE) wrote:=0A= > Thanks for digging this up... in the meantime of course there's been=0A= > work ongoing in the MMUSIC IETF WG that adds even more questions than=0A= > it answers. See messages from as recent as today about msid, bundle,=0A= > "unified plan", etc. (All useful work that is needed for other types=0A= > of SDP-using applications, like SIP-based videoconferencing systems,=0A= > but work that will take some time and which as long as we stick with=0A= > SDP as an API will be holding up the WEBRTC specification)=0A= >=0A= > As long as it is allowed for the SDP to be modified between=0A= > createOffer and setLocalDescription, there must be a W3C=0A= > specification instructing browser vendors as to what changes are and=0A= > are not allowed.=0A= =0A= Perhaps we should, at least initially, consider Martin's proposal: =0A= modifications are not allowed between createX and setLocal.=0A= =0A= >=0A= > Or, as I've pointed out before, we could define a browser API that is=0A= > entirely independent of SDP, and allow enough control that JavaScript=0A= > programmers can arrange objects and set their parameters such that=0A= > useful SRTP media streams can be sent and received, and then they can=0A= > write whatever JavaScript they want to create the SDP that is getting=0A= > defined over in MMUSIC and other places, or not use those specs if=0A= > they so desire.=0A= >=0A= > Matthew Kaufman=0A= >=0A= > ________________________________________ From: Martin Thomson=0A= > [martin.thomson@gmail.com] Sent: Thursday, July 18, 2013 9:53 AM To:=0A= > Peter Thatcher Cc: Matthew Kaufman (SKYPE); ;=0A= > public-webrtc@w3.org Subject: Re: [rtcweb] Summary of Application=0A= > Developers' opinions of the current WebRTC API and SDP as a control=0A= > surface=0A= >=0A= > On 18 July 2013 08:12, Peter Thatcher wrote:=0A= >> I believe I began paying attention to the mailing lists after you=0A= >> sent out theses slides that you didn't present. I'm interested in=0A= >> seeing them, and while I could dig through archives to find them,=0A= >> if convenient, could you please give me a link to the slides?=0A= >> Thanks.=0A= >=0A= > It wasn't actually November, it was October, which made this harder=0A= > to find than I had expected.=0A= >=0A= > http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/0148.html=0A= >=0A= >=0A= > _______________________________________________ rtcweb mailing list=0A= > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From ranjit.avasarala@nsn.com Fri Jul 19 04:00:20 2013 Return-Path: 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 13F9B11E80F8 for ; Fri, 19 Jul 2013 04:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 vujSK6Mnc3oK for ; Fri, 19 Jul 2013 04:00:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6672F11E80F6 for ; Fri, 19 Jul 2013 04:00:15 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6JB09AR018611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Jul 2013 13:00:09 +0200 Received: from SGSIHTC004.nsn-intra.net ([10.159.225.21]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6JAvHo8024061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 13:00:06 +0200 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.242]) by SGSIHTC004.nsn-intra.net ([10.159.225.21]) with mapi id 14.03.0123.003; Fri, 19 Jul 2013 18:58:39 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: "ext Muthu Arul Mozhi Perumal (mperumal)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoCAAAceUIAAG3TAgAAKkwCAAFNjgIAC8fcA Date: Fri, 19 Jul 2013 10:58:39 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10336 X-purgate-ID: 151667::1374231609-000017BA-B5D07BE6/0-0/0-0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 11:00:20 -0000 Hi Muthu So if I understand correctly, this functionality is on top of ICE functiona= lity and is optional for the gateways to support it. Right? Regards Ranjit -----Original Message----- From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Sent: Wednesday, July 17, 2013 7:48 PM To: Avasarala, Ranjit (NSN - IN/Bangalore) Cc: rtcweb@ietf.org Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-f= reshness-04.txt |-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.= com] |Sent: Wednesday, July 17, 2013 2:36 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |My comments inline | |Regards |Ranjit | |-----Original Message----- |From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |Sent: Wednesday, July 17, 2013 2:16 PM |To: Avasarala, Ranjit (NSN - IN/Bangalore) |Cc: rtcweb@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | ||If many public STUN servers and call servers that implement STUN or ICEli= te ||functionalities, are not expected to support | |I should have said they have no role to play. It is similar to peer-to-pee= r ICE connectivity checks -- |those checks don't go through public STUN or call servers at all. |[Ranjit] But there can be scenarios where RTCWebBrowsers do talk to WebRTC= Gateways which could be co- |located with call handling servers. Then it won't make sense to have this = feature. An RTCWeb gateway wouldn't have to do anything fancier than what it already= does for ICE connectivity checks.=20 | |The difference between ICE connectivity checks and consent freshness check= s is that the former is |performed before session establishment and the later is performed after se= ssion establishment. |[Ranjit] Why do you need to check consent of the peer after session is est= ablished? Ideally I should |check consent before session establishment. If the peer does not want to r= eceive traffic, then session |itself should not be established. See draft-ietf-rtcweb-security-arch: 4.4. Communications and Consent Freshness From a security perspective, everything from here on in is a little anticlimactic: Alice and Bob exchange data protected by the keys negotiated by DTLS. Because of the security guarantees discussed in the previous sections, they know that the communications are encrypted and authenticated. The one remaining security property we need to establish is "consent freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline. ICE specifies periodic STUN keepalizes but only if media is not flowing. Because the consent issue is more difficult here, we require RTCWeb implementations to periodically send keepalives. As described in Section 5.3, these keepalives MUST be based on the consent freshness mechanism specified in [I-D.muthu-behave-consent-freshness]. If a keepalive fails and no new ICE channels can be established, then the session is terminated. | ||then who would have interest to support this functionality? | |RTCWEB browsers and browser-like platforms. |[Ranjit] browser may implement, but it would be very customized one. I do = not think the intermediate |entities would want to support. You seem to be completely missing the very purpose of consent. | ||Ideally getting consent for receiving traffic or call should be part of s= ignaling. ||I do not think using STUN is appropriate. | |ICE already does that. You think it is inappropriate? |[Ranjit] I am saying that using STUN for consent check is not appropriate = as STUN has other dedicated |functionality to do - like connectivity checks, keep alives, etc.=20 See draft-ietf-rtcweb-security and draft-ietf-rtcweb-security. |Also in cases of Symmetric NATs where STUN fails, TURN is needed. Then the= proposed feature would anyway fail. The solution is built on top of ICE, so should work across these. Muthu | |Muthu | ||-----Original Message----- ||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn= .com] ||Sent: Wednesday, July 17, 2013 12:16 PM ||To: Muthu Arul Mozhi Perumal (mperumal) ||Cc: rtcweb@ietf.org ||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||Hi Muthu || ||If many public STUN servers and call servers that implement STUN or ICEli= te functionalities, are not ||expected to support, then who would have interest to support this functio= nality? Ideally getting ||consent for receiving traffic or call should be part of signaling. I do n= ot think using STUN is ||appropriate. || ||Regards ||Ranjit || || || || ||-----Original Message----- ||From: ext Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] ||Sent: Wednesday, July 17, 2013 12:07 PM ||To: Avasarala, Ranjit (NSN - IN/Bangalore) ||Cc: rtcweb@ietf.org; behave@ietf.org ||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent= -freshness-04.txt || ||Ranjit, || |||Many publicly available STUN servers or those that are part of Call serv= ers |||may not support this. || ||Public STUN servers and call servers are not expected to support this. || |||Can't there be some other neutral mechanism to query peer's consent - th= rough |||signaling? || ||No. That signaling between the JS and the web server could be anything (S= IP or XMPP or proprietary or ||whatever) and the browser has no control over it. || ||Muthu || |||-----Original Message----- |||From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@ns= n.com] |||Sent: Wednesday, July 17, 2013 11:19 AM |||To: Muthu Arul Mozhi Perumal (mperumal) |||Cc: rtcweb@ietf.org; behave@ietf.org |||Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consen= t-freshness-04.txt ||| |||Hi Muthu ||| |||Though using STUN request/response may be good for querying about consen= t, I feel it is overloading |||the functionality of STUN. Many publicly available STUN servers or those= that are part of Call ||servers |||may not support this. ||| |||Can't there be some other neutral mechanism to query peer's consent - th= rough signaling? ||| ||| |||Regards |||Ranjit ||| ||| ||| |||-----Original Message----- |||From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf= Of ext Simon Perreault |||Sent: Tuesday, July 16, 2013 6:34 PM |||To: Muthu Arul Mozhi Perumal (mperumal) |||Cc: rtcweb@ietf.org; behave@ietf.org |||Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consen= t-freshness-04.txt ||| |||Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |||> |> |> Liveness timer: If no packets have been received on the local= port in |||> |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript tha= t |||> |> |> connectivity has been lost. The JavaScript application will = use this |||> |> |> notification however it desires (e.g., cease transmitting to = the |||> |> |> remote peer, provide a notification to the user, etc.). |||> |> | |||> |> |This seems to me like it will not fulfill the goal set in the abst= ract: |||> |> |"to ensure that a malicious JavaScript cannot use the browser as a |||> |> |platform for launching attacks". If the JavaScript is free to igno= re the |||> |> |notification from the browser, then it has no security benefits. I= f you |||> |> |want to reach that goal, the browser needs to forcefully stop tran= smitting. |||> |> |||> |> That goal is fulfilled by the consent checks -- the browser would s= top transmitting everything ||on |||> |that candidate pair, including liveness checks, if there is a consent= failure. |||> | |||> |That's not what the draft says. It says that the browser "notifies" t= he |||> |JS app. It needs to say that the browser MUST stop sending. |||> |||> No. That section is about liveness check and its intention is just not= ify the JavaScript of a |||potential connectivity loss. It is when the consent check fails the brow= ser actually stops sending |||everything. Does the draft need more text on the distinction between con= sent and liveness tests? ||| |||Ah! No, you're right, and the text is already perfectly clear about |||this. No need to change. I was just confused. ||| |||> |> |> When not actively sending traffic on a nominated candidate pa= ir, |||> |> |> performing consent freshness does not serve any purpose from = a |||> |> |> security perspective. |||> |> | |||> |> |I don't understand what this means. Why is the "security perspecti= ve" |||> |> |important here? Aren't we concerned about keepalives? |||> |> |||> |> You mean one could use keepalives (Binding indications) for launchi= ng attacks, so consent |||freshness |||> |would be required for sending them as well? |||> | |||> |No. |||> | |||> |This is a section about keepalives. I just don't understand this |||> |sentence, and I don't understand why it talks about security. |||> |||> Ok, let me elaborate: |||> - Consent freshness is not necessary when the browser is not sending a= ny |||> traffic on a candidate pair. |||> - If the browser is not performing consent freshness on a candidate pa= ir |||> for the above reason, it performs ICE keepalives (or RTP keepalives)= to |||> refresh NAT bindings. |||> |||> Of course, the browser could continue performing consent freshness eve= n when it is not sending any |||other traffic on that candidate pair and skip ICE keepalives. ||| |||Ah, ok I understand with your explanation. It makes sense. There should |||be a way to reformulate the text to make it clearer. ||| |||Thanks, |||Simon |||_______________________________________________ |||rtcweb mailing list |||rtcweb@ietf.org |||https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Fri Jul 19 06:32:46 2013 Return-Path: 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 D106811E8120 for ; Fri, 19 Jul 2013 06:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=0.271, 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 8OTJdTYlaP4g for ; Fri, 19 Jul 2013 06:32:44 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9C76D11E8117 for ; Fri, 19 Jul 2013 06:32:44 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so9533134iea.32 for ; Fri, 19 Jul 2013 06:32:44 -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=sNXOXmw8EKbRAAw1QZCo1qOK2THNFdoLwgNWXkVo5Hg=; b=VMeTu4BCQ+OCl7M+ridcpBmJNIIXCQ7qHJ9iLbSue/z2CVj7MLjJC+TVkrBThPXAlB 3k9qXbRgPr2VgHcsTwyif3rfeMsS2NKA5WWJCnmrYzjkg1yeQ7V52avrLQXht5dARS1a PR4n+wDzpzVD7ykopMb/Squ4FZ7VJ8idfqG1pPOTBzSi4xGqT5RQbgHji4JhKHYlIFwk FJ9JrI1B/uupoNb+wckNqTxVZINmSAOuGEurfQ9G+TzFyifdITE2EwS8iSq+S7ZrGHCL kkY8pFO2AWJtkA3gVExp1ev0+fvECnWtFIX4m2GyNOuTvuQBlQwt1RyTIBgwVt9OYbCf 1LVQ== 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=sNXOXmw8EKbRAAw1QZCo1qOK2THNFdoLwgNWXkVo5Hg=; b=P54wb+nYz2Yf0wSe4Kh1DQ2BrEgl/j1og8VnONoL5vxp5186dWNgctpD3jyQSfsh1j elFKTCRfpp7pAsKNiLdop37/VpaezVn5EAqUvjIvShCdRBmL6hfjrFGAzevcRw4UBGiv 7mdIDygiKSkP4Kubxwhp/iV/kAM4w0sob8YnnIt8GnaaB2AFoRUEzL4cfpei6szU4bAO Ly32rj29VFE/rMyLUc3wQAt7hflXV2hCpnDg8DBnnd1zyi0x8bBnneijPMgZGTxRb4hJ 728k1Yc8bJVrjYBjI0n31RDYD0eBaLizQuzITDIQC8hTcovLZjwrrUEOR7Frja8rSg8K D1+w== X-Received: by 10.42.109.138 with SMTP id l10mr10160677icp.38.1374240763822; Fri, 19 Jul 2013 06:32:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.132 with HTTP; Fri, 19 Jul 2013 06:32:23 -0700 (PDT) In-Reply-To: References: <51E7324A.3090405@vline.me> <51E80DA2.4030500@vline.me> <51E8B3B8.3090502@vline.me> From: Justin Uberti Date: Fri, 19 Jul 2013 09:32:23 -0400 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=20cf303bf8be90697404e1dd5c94 X-Gm-Message-State: ALoCoQl50Lk6KC46dU8jn5YTHuMF7GYp3K8DCXTp/bDZkuK4LUWQUPsnSnQfrP1MyvlFv1x2mw6YXJve3Z2YeyH6NgKnQiKyjOgfpiObbAWk6JMFAzhtRxhjoF/ZwYAvQ1lHS3HzNAMLPxCMxGmiuDXrWu+jNsfs6QLBIayNEj7l5GpMtdhYFTCCNyFJJC5erPQqFR6coCk/ Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:32:46 -0000 --20cf303bf8be90697404e1dd5c94 Content-Type: text/plain; charset=UTF-8 Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba wrote: > If we can support VP8/9 as well as H.264/5 SVC > that would be a start. It seems doable to me. > > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" wrote: > > Bernard, > > Are there other codecs you are thinking should be supported? If it's > generalized I would think we want to be able to cover all known scalable > codecs. I'll look into the H264/SVC fields to see how to encode them in a > generalized header. > > Regards, > Adam > > On 7/18/13 7:40 PM, Bernard Aboba wrote: > > I think it may be possible to generalize this. For example, for H.264/SVC > which can support temporal, spatial and quality scalability, you would need > the quality_id and dependency_id in addition to the temporal_id (what you > call the temporal layer index). > > ------------------------------ > Date: Thu, 18 Jul 2013 08:45:38 -0700 > From: fineberg@vline.me > To: bernard_aboba@hotmail.com > CC: rtcweb@ietf.org; avtext@ietf.org > Subject: Re: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Bernard, > > Good question. I'm not familiar enough with the parameter requirements of > all other scalable codecs to be able to generalize. If you'd like to help > specify them, I'd be fine revising the draft to generalize. > > Regards, > Adam > > On 7/17/13 8:26 PM, Bernard Aboba wrote: > > Since the need is not codec specific (e.g. it arises with any codec > supporting temporal, spatial and quality scalability), why > a VP8-specific RTP extension? > > ------------------------------ > Date: Wed, 17 Jul 2013 17:09:46 -0700 > From: fineberg@vline.me > To: rtcweb@ietf.org > Subject: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found that while developing > services that forward VP8 video streams if we want to take advantage of the > VP8 temporal scaling we must get the temporal layer information from the > RTP header which requires us to decrypt the SRTP packets. This is > undesirable both because the middle-box needs to have access to the keys as > well as the because of the added overhead of the decrypt/encrypt cycle. > This draft proposes an RTP header extension that will allow us to use the > VP8 temporal layer information included in the header extension and > therefore do forwarding without SRTP decryption. Comments welcome. > > Regards, > Adam Fineberg > fineberg at vline.com > > -------- Original Message -------- Subject: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt Date: Tue, 09 Jul 2013 > 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg at vline.com> > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > has been successfully submitted by Adam Fineberg and posted to the > IETF repository. > > Filename: draft-fineberg-avtext-temporal-layer-ext > Revision: 00 > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > Abstract: > This document defines a mechanism by which packets of Real-Time > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > indicate, in an RTP header extension, the temporal layer information > about the frame encoded in the RTP packet. This information can be > used in a middlebox performing bandwidth management of streams > without requiring it to decrypt the streams. > > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Regards, > Adam > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf303bf8be90697404e1dd5c94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree those are the right codecs to design for. Since in e= ach case there are fairly low limits on the number of supported layers (i.e= . 3 spatial layers for SVC), I think it should be possible to pack the temp= oral, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard= Aboba <bernard_aboba@hotmail.com> wrote:
If we can support VP8= /9 as well as H.264/5 SVC
that would be a start. It seems doable = to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" &= lt;fineberg@vline.me= > wrote:

=20 =20 =20 =20
Bernard,

Are there other codecs you are thinking should be supported?=C2=A0 If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
=20
I think it may be possible to generalize this.=C2=A0= For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index). =C2=A0=C2=A0

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fine= berg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@i= etf.org; avtext@ie= tf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.=C2=A0 I'm not familiar enough with the paramet= er requirements of all other scalable codecs to be able to generalize.=C2=A0 If you'd like to help specify them, I'd= be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
=20
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
=C2=A0a VP8-specific RTP extension?
=C2=A0
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rt= cweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.co= m

-------- Original Message --------
Subj= ect: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date= : Tue, 09 Jul 2013 10:02:05 -0700
From= : internet-drafts at ietf.org
To:<= /th> Adam Fineberg=C2=A0<finebe= rg at vline.com> 


A new =
version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             ht=
tp://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-=
00.txt
Status:          http://datatr=
acker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ie=
tf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

--=20
Regards,
Adam

=20

__________________________________= _____________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


--20cf303bf8be90697404e1dd5c94-- From fluffy@iii.ca Fri Jul 19 06:42:52 2013 Return-Path: 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 001AB11E812C; Fri, 19 Jul 2013 06:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] 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 tpaSUJ1AYKcx; Fri, 19 Jul 2013 06:42:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6518011E8118; Fri, 19 Jul 2013 06:42:47 -0700 (PDT) Received: from [10.171.47.8] (unknown [209.121.225.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1EF4A509B8; Fri, 19 Jul 2013 09:42:38 -0400 (EDT) References: <51E7324A.3090405@vline.me> <51E80DA2.4030500@vline.me> <51E8B3B8.3090502@vline.me> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-120029B0-280A-471C-8749-E808561C9BC6 Message-Id: X-Mailer: iPad Mail (10B329) From: Cullen Jennings Date: Fri, 19 Jul 2013 06:42:38 -0700 To: Bernard Aboba Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:42:52 -0000 --Apple-Mail-120029B0-280A-471C-8749-E808561C9BC6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable That's the set of codecs that seems interesting to most people right now On Jul 18, 2013, at 10:56 PM, Bernard Aboba wrot= e: > If we can support VP8/9 as well as H.264/5 SVC > that would be a start. It seems doable to me. >=20 > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" wrote: >=20 >> Bernard, >>=20 >> Are there other codecs you are thinking should be supported? If it's gen= eralized I would think we want to be able to cover all known scalable codecs= . I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. >>=20 >> Regards, >> Adam >>=20 >> On 7/18/13 7:40 PM, Bernard Aboba wrote: >>> I think it may be possible to generalize this. For example, for H.264/S= VC which can support temporal, spatial and quality scalability, you would ne= ed the quality_id and dependency_id in addition to the temporal_id (what you= call the temporal layer index). =20 >>>=20 >>> Date: Thu, 18 Jul 2013 08:45:38 -0700 >>> From: fineberg@vline.me >>> To: bernard_aboba@hotmail.com >>> CC: rtcweb@ietf.org; avtext@ietf.org >>> Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-a= vtext-temporal-layer-ext-00.txt >>>=20 >>> Bernard, >>>=20 >>> Good question. I'm not familiar enough with the parameter requirements o= f all other scalable codecs to be able to generalize. If you'd like to help= specify them, I'd be fine revising the draft to generalize. >>>=20 >>> Regards, >>> Adam >>>=20 >>> On 7/17/13 8:26 PM, Bernard Aboba wrote: >>> Since the need is not codec specific (e.g. it arises with any codec supp= orting temporal, spatial and quality scalability), why=20 >>> a VP8-specific RTP extension?=20 >>> =20 >>> Date: Wed, 17 Jul 2013 17:09:46 -0700 >>> From: fineberg@vline.me >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtex= t-temporal-layer-ext-00.txt >>>=20 >>> Hi, >>>=20 >>> I'm working on WebRTC services and have found that while developing serv= ices that forward VP8 video streams if we want to take advantage of the VP8 t= emporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both b= ecause the middle-box needs to have access to the keys as well as the becaus= e of the added overhead of the decrypt/encrypt cycle. This draft proposes an= RTP header extension that will allow us to use the VP8 temporal layer infor= mation included in the header extension and therefore do forwarding without S= RTP decryption. Comments welcome. >>>=20 >>> Regards, >>> Adam Fineberg >>> fineberg at vline.com >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-fineberg-avtext-temporal= -layer-ext-00.txt >>> Date: Tue, 09 Jul 2013 10:02:05 -0700 >>> From: internet-drafts at ietf.org >>> To: Adam Fineberg >>>=20 >>> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >>> has been successfully submitted by Adam Fineberg and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-fineberg-avtext-temporal-layer-ext >>> Revision: 00 >>> Title: A Real-Time Transport Protocol (RTP) Header Extens= ion for VP8 Temporal Layer Information >>> Creation date: 2013-07-08 >>> Group: Individual Submission >>> Number of pages: 6 >>> URL: http://www.ietf.org/internet-drafts/draft-fineberg-avte= xt-temporal-layer-ext-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-t= emporal-layer-ext >>> Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-tempor= al-layer-ext-00 >>>=20 >>>=20 >>> Abstract: >>> This document defines a mechanism by which packets of Real-Time >>> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >>> indicate, in an RTP header extension, the temporal layer information >>> about the frame encoded in the RTP packet. This information can be >>> used in a middlebox performing bandwidth management of streams >>> without requiring it to decrypt the streams. >>>=20 >>> _______________________________________________ rtcweb mailing list rtcw= eb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>> --=20 >>> Regards, >>> Adam > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --Apple-Mail-120029B0-280A-471C-8749-E808561C9BC6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
That's the set of codecs that seems interesting to most people right now

On Jul 18, 2013, at 10:56 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

-- 
Regards,
Adam

_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext
--Apple-Mail-120029B0-280A-471C-8749-E808561C9BC6-- From fluffy@iii.ca Fri Jul 19 06:56:58 2013 Return-Path: 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 28CE111E8249 for ; Fri, 19 Jul 2013 06:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] 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 M84iLweEs5Is for ; Fri, 19 Jul 2013 06:56:53 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 861AC11E81E6 for ; Fri, 19 Jul 2013 06:56:53 -0700 (PDT) Received: from [10.171.47.8] (unknown [209.121.225.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 45AF950A86; Fri, 19 Jul 2013 09:56:52 -0400 (EDT) References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (10B329) From: Cullen Jennings Date: Fri, 19 Jul 2013 06:56:52 -0700 To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:56:58 -0000 Please tell us the use case you have that requires this and it will make it e= asier to figure out how to solve the pain.=20 On Jul 8, 2013, at 1:43 PM, I=C3=B1aki Baz Castillo wrote: > 2013/7/8 Stefan H=C3=A5kansson LK : >>> So, was there ever a consensus that "developers MUST NOT >>> touch SDP"? >>=20 >> No, developers are free to touch the SDP (and probably must in certain >> cases). >=20 >=20 > Do you feel how much painful is "touching a browser generated SDP"? To be c= lear: >=20 > - JS requests "A" to browser. > - Browser returns "A" (in the form of unmanageable blob). > - JS modifies "A" to send "A-bis" in the wire. > - Remote peer receives "A-bis" and replies "B-bis". > - Both JS app are lying to their respective browsers to get the > desired behavior. >=20 > This is really painful, really. >=20 > In the other side, as I explained in other thread (may be in this > one?) adding some methods to the current API (to avoid playing with > the SDP) is not the way to go. A specification in which the JS app > does not know what he is sending in-the-wire (a blob generated by the > browser) is doomed to failure. >=20 > Please remember that mandating SDP (plain SDP) means that no other > media signaling protocol can be implemented in future WebRTC apps. >=20 > SIP phones have *fixed* code and *fixed* logic. This is no longer true > in the Web. >=20 > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Fri Jul 19 07:00:29 2013 Return-Path: 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 4F6AA21E80B9 for ; Fri, 19 Jul 2013 07:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] 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 Mmoptp0KeQg4 for ; Fri, 19 Jul 2013 07:00:24 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id BED3A21E80C8 for ; Fri, 19 Jul 2013 07:00:23 -0700 (PDT) Received: from [10.171.47.8] (unknown [209.121.225.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E98B650A89; Fri, 19 Jul 2013 10:00:22 -0400 (EDT) References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (10B329) From: Cullen Jennings Date: Fri, 19 Jul 2013 07:00:24 -0700 To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:00:29 -0000 Can someone please email a full copy of the spreadsheet to the list so it is= in the archives - thanks On Jul 9, 2013, at 3:18 AM, I=C3=B1aki Baz Castillo wrote: > 2013/7/9 Stefan H=C3=A5kansson LK : >> I want to be very clear and careful on what I say. So I am repeating: >>=20 >> * My comment that I think Eric is right in that there is consensus on >> providing APIs that allow most use-cases to be met without SDP mangling >> is meant only in that context: SDP O/A is kept (and PeerConnection more >> or less as is and so on). >=20 > Hi Stefan, >=20 > You insist that "there is consensus on keeping SDP O/A but providing a > better API". Given current discussions IMHO it is clear there is not > such a consensus (not at all). Or may be you are just talking about > two years ago in some IETF meeting (if so I'm sorry). >=20 > Please review the results in > https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdHl= ZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1 >=20 > Bad for advanced stuff: 94% > OK for 1.0: 40% >=20 > IMHO such a result indicates all but "let's keep SDP O/A and improve a > bit the API" (I mean now, in July 2013). >=20 >=20 > Best regards. >=20 >=20 >=20 > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Fri Jul 19 07:04:12 2013 Return-Path: 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 F186D21E80D0 for ; Fri, 19 Jul 2013 07:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.416 X-Spam-Level: X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] 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 9m3fdtodMdZq for ; Fri, 19 Jul 2013 07:04:07 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF1721E80B8 for ; Fri, 19 Jul 2013 07:04:07 -0700 (PDT) Received: from [10.171.47.8] (unknown [209.121.225.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1B485509B6; Fri, 19 Jul 2013 10:04:00 -0400 (EDT) References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (10B329) From: Cullen Jennings Date: Fri, 19 Jul 2013 07:04:01 -0700 To: "Matthew Kaufman (SKYPE)" Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:04:12 -0000 Folks wanted to sort out how mindless works fist before getting to theses sm= aller details but in general I think progress is being made on all of these On Jul 17, 2013, at 2:58 PM, "Matthew Kaufman (SKYPE)" wrote: > Bernard Aboba: >>=20 >> The problem was that we never defined what mangling browsers had to >> support. Given all the SDP specs that is actually a huge work item. >=20 >=20 > This is exactly what my slides that weren't presented last November starte= d to touch upon. It only takes a few minutes with RFC3264 and its references= to start documenting cases that are clearly "valid SDP offer/answer" and ye= t for which I cannot for the life of me figure out what a browser should do i= f they're presented. >=20 > Just off the top of my head: >=20 > Can I... > - Change the t=3D line to be something other than t=3D0 0? > - Change the rtpmap associations before calling setLocal? > - Change a=3Dsendrecv to a=3Drecvonly before calling setLocal? > - What do you do when you see a=3Dcontent:sl ? > - What if someone adds an r=3D or p=3D or e=3D? > - What is the RFC that describes a=3Dgroup:BUNDLE (as seen in some browser= implementations)? > - Can I remove a=3Dgroup:BUNDLE (or add it) before calling setLocal? > - How about removing a=3Drtcp-mux? > - Should I do something special at my end if you set a=3Dice-options:googl= e-ice ? > - If you put a=3Dssrc lines in there, can I change the ssrc before passing= it back to setLocal? > - Can I delete the a=3Dssrc lines? > - Is a=3Drtcp:1 IN IP4 0.0.0.0 valid or not? > - What about 0.0.0.0 in the o=3D line? > - If I get a bunch of a=3Dcandidate lines, can I swap them around to chang= e the priority before calling setLocal? > - What if someone claims SAVP instead of SAVPF but gives me rtcp info? > =20 > At the *very least* for each and every line that comes from createOffer an= d createAnswer you must be able to answer the following: > - Can I delete it? > - Duplicate it? > - Change it? > - If not, how are violation handled? (Both when passed to another browser a= t the far end and when these modifications happen before calling setLocal) > - And can I add additional valid SDP to what came from createOffer or crea= teAnswer and pass it back to setLocal or not? >=20 > We appear to be nowhere near a document which explains the answers to thes= e questions, certainly not in the W3C WG, and not in any IETF RFC or draft I= can locate. >=20 > Matthew Kaufman >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Fri Jul 19 07:24:33 2013 Return-Path: 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 6BBA311E813A for ; Fri, 19 Jul 2013 07:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619] 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 JstjGmJmNNz0 for ; Fri, 19 Jul 2013 07:24:27 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3567F11E812C for ; Fri, 19 Jul 2013 07:24:27 -0700 (PDT) Received: from [10.171.47.8] (unknown [209.121.225.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A35BF50A73; Fri, 19 Jul 2013 10:24:25 -0400 (EDT) References: <51DC3644.4020107@bbs.darktech.org> <51DC8445.2030902@bbs.darktech.org> In-Reply-To: <51DC8445.2030902@bbs.darktech.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (10B329) From: Cullen Jennings Date: Fri, 19 Jul 2013 07:24:26 -0700 To: cowwoc Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:24:33 -0000 On Jul 9, 2013, at 2:44 PM, cowwoc wrote: > Three weeks ago I posted a summary of discussion points that came up in= the WebRTC World conference (most of which had to do with the WebRTC API). T= o date, I have not received a reply from any of the people you have listed. I= am unable to gather the necessary momentum to turn these points into action= items without your help. I was/am frustrated that the spec editors and vend= ors are responsible to engage the community on these matters, but did not. I= hope this clarifies what I meant. Many of us have been very busy updating drafts for ietf deadline so it as be= en a hard time to respond.=20= From matthew.kaufman@skype.net Fri Jul 19 07:33:36 2013 Return-Path: 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 ; 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 ; 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 ; 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)" To: Silvia Pfeiffer , Martin Thomson 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: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> , In-Reply-To: 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: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:33:36 -0000 You say... "But I see the full definition of the SDP=0A= parameters that browsers have to support as less important and=0A= potentially just a by product of creating the higher level APIs."=0A= =0A= But I'm afraid that as a browser vendor, I will need exactly such a specifi= cation in order to create an interoperable browser without looking at the o= ther 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 sur= faces.=0A= =0A= Matthew Kaufman=0A= =0A= ________________________________________=0A= From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Silvia= Pfeiffer [silviapfeiffer1@gmail.com]=0A= Sent: Thursday, July 18, 2013 5:46 PM=0A= To: Martin Thomson=0A= Cc: ; public-webrtc@w3.org=0A= Subject: Re: [rtcweb] Summary of Application Developers' opinions of the cu= rrent WebRTC API and SDP as a control surface=0A= =0A= On Fri, Jul 19, 2013 at 2:53 AM, Martin Thomson=0A= wrote:=0A= > On 18 July 2013 08:12, Peter Thatcher wrote:=0A= >> I believe I began paying attention to the mailing lists after you sent o= ut=0A= >> theses slides that you didn't present. I'm interested in seeing them, a= nd=0A= >> while I could dig through archives to find them, if convenient, could yo= u=0A= >> please give me a link to the slides? Thanks.=0A= >=0A= > It wasn't actually November, it was October, which made this harder to=0A= > find than I had expected.=0A= >=0A= > http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/0148.html=0A= =0A= =0A= This captures exactly the kind of questions and concerns I had. Excellent w= ork!=0A= =0A= However, I don't fully agree with the conclusion of the slide deck.=0A= I'd prefer we extended the constraints and other browser APIs that set=0A= the SDP parameters rather than (or: in preference to) fully specifying=0A= what SDP the browser has to support. I do like the ability to get the=0A= low-level access to mangle the SDP as a means of experimenting with=0A= new functionality or as a means to try and connect to devices that=0A= don't have a WebRTC API. But I see the full definition of the SDP=0A= parameters that browsers have to support as less important and=0A= potentially just a by product of creating the higher level APIs.=0A= =0A= What does it take for us to get focused on defining such an API that=0A= is independent of SDP for the JS developer, and for now requires=0A= browsers to do the mapping to SDP for them? Is the extension of the=0A= constraints that a JS dev can manipulate enough for this?=0A= =0A= Silvia.=0A= _______________________________________________=0A= rtcweb mailing list=0A= rtcweb@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtcweb=0A= =0A= From pthatcher@google.com Fri Jul 19 07:50:33 2013 Return-Path: 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 19AEA11E8145 for ; Fri, 19 Jul 2013 07:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, 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 vaKfS9XYRoDm for ; Fri, 19 Jul 2013 07:50:32 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0538D11E82A8 for ; Fri, 19 Jul 2013 07:50:31 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rl6so4539295pac.15 for ; Fri, 19 Jul 2013 07:50:31 -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=m1IX8oQiQCtdjWauWKQ+nGhd6vU3Ad4ALWeQk8Xhx0k=; b=ZvedtwG/I8oEiJ2MjEoWdWxztNexqfdro3pRySAfYh5XvcBNPo++QlIJQN2hfHE8t7 tqwQETAeNEVpYVh5e3f0cBbnmFBB6OohtjE6LXwBYchd3yCw7/ue1Oqe/Dq5jM2q9JjQ OpOLXIV8VUTj962AabVob1maH9V4J/GJkHBLoxMWMOURDkn2DyYAj4rYB7Bz2Lpz0NPL 94P3GlnFO14X2MZexn30nEgdXiBoRBIOLO0HIrog6tcO5SPmnaQJ8Qc9t2oUDocPy/MO gPZJV0oAHUsTFsnLrvfGUUe6dJ0A6BKDEhNl+YfX4Coz1LsXE+JR3KzwTZi6hNWcgj78 CFoQ== 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=m1IX8oQiQCtdjWauWKQ+nGhd6vU3Ad4ALWeQk8Xhx0k=; b=eyNoGC1K//Ma15P/UXMRRsyzzhf0CCGxfWvOduRDZwBA6Z9yKE0tfAe+uvlfRMmvpt HO8K7zOyN8m8fZQui7eJYMQNNqENIJ8WTI4oNRSrq1xEE3xcc/gF8Dx7wmCjszoEcpW5 JuNfNDadJAyRIh2gC0XndN4b/CF9nNnJ2enW13JtHV5Bto2bqVlpeCuAJ+9On04TCopl PhMy8bSg1U4wnmL+GXqkMeLTAcjvC7DenEwhH5cVs6uiSh5hek3xqM2femBjKG4MqKQ9 lL9RT8izk+a3m11AUWDlcaZ+RNokcawqxknwtRRpt8MIBPyPpSxvHVeKD09ikvdIPtRA 0MFA== X-Received: by 10.66.217.195 with SMTP id pa3mr18790194pac.120.1374245431690; Fri, 19 Jul 2013 07:50:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 07:49:50 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Fri, 19 Jul 2013 07:49:50 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7b5d438cca6ee504e1de72a1 X-Gm-Message-State: ALoCoQmg5TZvJSYAjf65aIfdz6bxWdMIyGpaz9NU6XDMTDvLWnMCCBha6SRIBuLZGZzH2+uW/GQCoOkXngEtQLYwtcCDOy7ZncLur6hvg+eZsJY/nbs4gMRKjRS6u3b+cLughP5yLLohY0EMEO+0PejgI/4iWOPt5J6UMSrJSjdx9Q/cYhPQmMLwK+zGbYxDs/OtHqC2vF7u Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:50:33 -0000 --047d7b5d438cca6ee504e1de72a1 Content-Type: text/plain; charset=UTF-8 "mindless works fist"? There's a deep meaning there, but I'm still trying to figure it out... On Fri, Jul 19, 2013 at 7:04 AM, Cullen Jennings wrote: > Folks wanted to sort out how mindless works fist before getting to theses > smaller details but in general I think progress is being made on all of > these > > On Jul 17, 2013, at 2:58 PM, "Matthew Kaufman (SKYPE)" < > matthew.kaufman@skype.net> wrote: > > > Bernard Aboba: > >> > >> The problem was that we never defined what mangling browsers had to > >> support. Given all the SDP specs that is actually a huge work item. > > > > > > This is exactly what my slides that weren't presented last November > started to touch upon. It only takes a few minutes with RFC3264 and its > references to start documenting cases that are clearly "valid SDP > offer/answer" and yet for which I cannot for the life of me figure out what > a browser should do if they're presented. > > > > Just off the top of my head: > > > > Can I... > > - Change the t= line to be something other than t=0 0? > > - Change the rtpmap associations before calling setLocal? > > - Change a=sendrecv to a=recvonly before calling setLocal? > > - What do you do when you see a=content:sl ? > > - What if someone adds an r= or p= or e=? > > - What is the RFC that describes a=group:BUNDLE (as seen in some browser > implementations)? > > - Can I remove a=group:BUNDLE (or add it) before calling setLocal? > > - How about removing a=rtcp-mux? > > - Should I do something special at my end if you set > a=ice-options:google-ice ? > > - If you put a=ssrc lines in there, can I change the ssrc before passing > it back to setLocal? > > - Can I delete the a=ssrc lines? > > - Is a=rtcp:1 IN IP4 0.0.0.0 valid or not? > > - What about 0.0.0.0 in the o= line? > > - If I get a bunch of a=candidate lines, can I swap them around to > change the priority before calling setLocal? > > - What if someone claims SAVP instead of SAVPF but gives me rtcp info? > > > > At the *very least* for each and every line that comes from createOffer > and createAnswer you must be able to answer the following: > > - Can I delete it? > > - Duplicate it? > > - Change it? > > - If not, how are violation handled? (Both when passed to another > browser at the far end and when these modifications happen before calling > setLocal) > > - And can I add additional valid SDP to what came from createOffer or > createAnswer and pass it back to setLocal or not? > > > > We appear to be nowhere near a document which explains the answers to > these questions, certainly not in the W3C WG, and not in any IETF RFC or > draft I can locate. > > > > Matthew Kaufman > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b5d438cca6ee504e1de72a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"mindless works fist"? =C2=A0There's a deep= meaning there, but I'm still trying to figure it out...


On Fri, Jul 19, 2013 at 7:04 AM, Cullen = Jennings <fluffy@iii.ca> wrote:
matthew.kaufman@skype.net> wr= ote:

> Bernard Aboba:
>>
>> The problem was that we never defined what mangling browsers had t= o
>> support. Given all the SDP specs that is actually a huge work item= .
>
>
> This is exactly what my slides that weren't presented last Novembe= r started to touch upon. It only takes a few minutes with RFC3264 and its r= eferences to start documenting cases that are clearly "valid SDP offer= /answer" and yet for which I cannot for the life of me figure out what= a browser should do if they're presented.
>
> Just off the top of my head:
>
> Can I...
> - Change the t=3D line to be something other than t=3D0 0?
> - Change the rtpmap associations before calling setLocal?
> - Change a=3Dsendrecv to a=3Drecvonly before calling setLocal?
> - What do you do when you see a=3Dcontent:sl ?
> - What if someone adds an r=3D or p=3D or e=3D?
> - What is the RFC that describes a=3Dgroup:BUNDLE (as seen in some bro= wser implementations)?
> - Can I remove a=3Dgroup:BUNDLE (or add it) before calling setLocal? > - How about removing a=3Drtcp-mux?
> - Should I do something special at my end if you set a=3Dice-options:g= oogle-ice ?
> - If you put a=3Dssrc lines in there, can I change the ssrc before pas= sing it back to setLocal?
> - Can I delete the a=3Dssrc lines?
> - Is a=3Drtcp:1 IN IP4 0.0.0.0 valid or not?
> - What about 0.0.0.0 in the o=3D line?
> - If I get a bunch of a=3Dcandidate lines, can I swap them around to c= hange the priority before calling setLocal?
> - What if someone claims SAVP instead of SAVPF but gives me rtcp info?=
>
> At the *very least* for each and every line that comes from createOffe= r and createAnswer you must be able to answer the following:
> - Can I delete it?
> - Duplicate it?
> - Change it?
> - If not, how are violation handled? (Both when passed to another brow= ser at the far end and when these modifications happen before calling setLo= cal)
> - And can I add additional valid SDP to what came from createOffer or = createAnswer and pass it back to setLocal or not?
>
> We appear to be nowhere near a document which explains the answers to = these questions, certainly not in the W3C WG, and not in any IETF RFC or dr= aft I can locate.
>
> Matthew Kaufman
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b5d438cca6ee504e1de72a1-- From pthatcher@google.com Fri Jul 19 07:52:24 2013 Return-Path: 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 E3E6B11E8205 for ; Fri, 19 Jul 2013 07:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.449 X-Spam-Level: ** X-Spam-Status: No, score=2.449 tagged_above=-999 required=5 tests=[AWL=-4.229, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, J_CHICKENPOX_102=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6, NO_RELAYS=-0.001, WEIRD_QUOTING=1.396] 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 tUAnB6sNjzKp for ; Fri, 19 Jul 2013 07:52:19 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8A411E8145 for ; Fri, 19 Jul 2013 07:52:16 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 10so4376182pdc.33 for ; Fri, 19 Jul 2013 07:52:16 -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=6Fi3CRs/o5MpEJgIx73Au8v8MGyYIYX78YI27vtU+J0=; b=L1YvjsAunKT+9U15HneCi2SXHxSimMe8t8IQX2lHCrkgwz8Cw+0UDUPvXmJsQyd0M0 MuQuqoHn9c6ZVxi89OntT13u/DmEk4SBin0RBqIxDyFl1wVJoKF1jwhAt7GjEJKE5kCW rtHDdUQmLK7Ess4gPxXzNT1B2E8zMkhQAYsAUVkBodGkWeXr6R/bNu8WKBFFKyBd16Oe TNUPD28AaM1koKIvuGeKUvE5XtF/hX7LPJwQKT0aQwIRwFgKTP34vnq50jvBPXauhLVC KCtU7Cq9E7urHxUh/T6R8IVTSthSOhrqLnkmIZ1yyKxmWjhgicTYRZH8Cr1wp1Ds+RJC A+TA== 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=6Fi3CRs/o5MpEJgIx73Au8v8MGyYIYX78YI27vtU+J0=; b=X7b0o5mn15nWS4ChdBTatKmbWKlfMK0U9YSiX2LHngo/CxTUISBz8VzFJcKbXBjZCM GdRE848UU7QZAkRM14AIsUsnVz/inn1lzNDJTAKxfLeMCnmZAVLHJms8FO2DeZVLUIMr XDqSFQ4ixjAvGJduTBlDSraC2seO2gBg2sxyIruehJBeDtW8P2B+sM/KYjecUXdZMCyQ CXKemz0Da67FCThvAf6tFknv6Hu6U8RZc70ebHnHJE8ElbHJ35X4Scp2mEldYLx/w1mD h4Fz/52ZwGRTc76ayWTudRRhcpQkw6uJYMfPt81aI8LB/XEF2OqympRKY5hFMJzYpI1e ml8Q== X-Received: by 10.66.141.4 with SMTP id rk4mr18456613pab.127.1374245536099; Fri, 19 Jul 2013 07:52:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 07:51:34 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Fri, 19 Jul 2013 07:51:34 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/mixed; boundary=001a11c39d18038e6604e1de7955 X-Gm-Message-State: ALoCoQkd6AJzQdE40PgZ0gaBfDxP07ZFtuVMDX3EGThAsklERfLIXvixUWmYpUuY7Pmfy2sWdkvbgY/D9ZHQhXt4GFZLTrYNXPFmgSy2e4VcXwArrTBDjOP2Hg2jRZGK9DBHuDQtzIOsp1H8eupAOb3RfmZImi4IL77rSzemoIe6Ji0NAx2GJWtskK3MWoKWpWVry+gnU6Aw Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:52:24 -0000 --001a11c39d18038e6604e1de7955 Content-Type: multipart/alternative; boundary=001a11c39d18038e6304e1de7953 --001a11c39d18038e6304e1de7953 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here you go: On Fri, Jul 19, 2013 at 7:00 AM, Cullen Jennings wrote: > Can someone please email a full copy of the spreadsheet to the list so it > is in the archives - thanks > > On Jul 9, 2013, at 3:18 AM, I=C3=B1aki Baz Castillo wrote= : > > > 2013/7/9 Stefan H=C3=A5kansson LK : > >> I want to be very clear and careful on what I say. So I am repeating: > >> > >> * My comment that I think Eric is right in that there is consensus on > >> providing APIs that allow most use-cases to be met without SDP manglin= g > >> is meant only in that context: SDP O/A is kept (and PeerConnection mor= e > >> or less as is and so on). > > > > Hi Stefan, > > > > You insist that "there is consensus on keeping SDP O/A but providing a > > better API". Given current discussions IMHO it is clear there is not > > such a consensus (not at all). Or may be you are just talking about > > two years ago in some IETF meeting (if so I'm sorry). > > > > Please review the results in > > > https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdH= lZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1 > > > > Bad for advanced stuff: 94% > > OK for 1.0: 40% > > > > IMHO such a result indicates all but "let's keep SDP O/A and improve a > > bit the API" (I mean now, in July 2013). > > > > > > Best regards. > > > > > > > > -- > > I=C3=B1aki Baz Castillo > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c39d18038e6304e1de7953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here you go:




On Fri, Jul 19, 2013 at= 7:00 AM, Cullen Jennings <fluffy@iii.ca> wrote:
Can someone please email a full copy of the = spreadsheet to the list so it is in the archives - thanks

On Jul 9, 2013, at 3:18 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:

> 2013/7/9 Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com>:
>> I want to be very clear and careful on what I say. So I am repeati= ng:
>>
>> * My comment that I think Eric is right in that there is consensus= on
>> providing APIs that allow most use-cases to be met without SDP man= gling
>> is meant only in that context: SDP O/A is kept (and PeerConnection= more
>> or less as is and so on).
>
> Hi Stefan,
>
> You insist that "there is consensus on keeping SDP O/A but provid= ing a
> better API". Given current discussions IMHO it is clear there is = not
> such a consensus (not at all). Or may be you are just talking about > two years ago in some IETF meeting (if so I'm sorry).
>
> Please review the results in
> http= s://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdHlZdV9R= N0xSWFhybVl4anJLRkVPV0E#gid=3D1
>
> =C2=A0Bad for advanced stuff: 94%
> =C2=A0OK for 1.0: 40%
>
> IMHO such a result indicates all but "let's keep SDP O/A and = improve a
> bit the API" (I mean now, in July 2013).
>
>
> Best regards.
>
>
>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c39d18038e6304e1de7953-- --001a11c39d18038e6604e1de7955 Content-Type: text/csv; name="Input from JS Developers on their experience with the WebRTC API - Inputs.csv" Content-Disposition: attachment; filename="Input from JS Developers on their experience with the WebRTC API - Inputs.csv" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hjbia49o0 TmFtZSBvciBlbWFpbCxXaGF0IGFyZSB5b3UgdXNpbmcgaXQgZm9yPyxXaGF0IGhhcyB3b3JrZWQg d2VsbD8sV2hhdCdzIHRoZSBiaWdnZXN0IHBhaW4gcG9pbnQ/LERvIHlvdSBoYXZlIGFuIG9waW5p b24gb24gU0RQIG9yIE8vQSBhcyB0aGUgQVBJIHN1cmZhY2U/LFF1b3RlcyBmcm9tIG1haWxpbmcg bGlzdCBhYm91dCBTRFAsU3VtbWFyYXRpdmUgb3BpbmlvbixEaWQgeW91IGNoYW5nZSB5b3VyIG1p bmQgYWJvdXQgdGhlIFNEUCBBUEkgc2luY2UgaXQgd2FzIGZpcnN0IHByb3Bvc2VkPwpNYXJjIEFi cmFtcywsLCwiSWYgdGhlIHB1cnBvc2UgZm9yIGluY2x1ZGluZyBTRFAgaXMgY29tcGF0aWJpbGl0 eSB3aXRoIGV4aXN0aW5nIHNlcnZpY2VzIG9yIHByb3RvY29scywgdGhlcmUgYXJlIGJldHRlciB3 YXlzIHRvIGVuc3VyZSB0aGlzLiIsV2Ugc2hvdWxkIHB1bnQgb24gU0RQIGZvciB2MS4wIGFuZCBt b3ZlIG9uLiAsKHN0cm9uZyBkaXNsaWtlKSxObwpJw7Fha2kgQmF6IENhc3RpbGxvLFNJUCBvdmVy IFdlYlNvY2tldC4sTm90LiBMb3Qgb2YgaXNzdWVzIGR1ZSB0byBTRFAgdXNhZ2UuIEl0IGlzIHRv byBoYXJkIGFuZCBlcnJvciBwcnVuZSB0byBtYW5nbGUgYSBTRFAgZnJvbSBhbnkgYnJvd3Nlci92 ZXJzaW9uL2ZsYXZvdXIuLFNEUCBibG9iIGFuZCBPL0EgYXJ0aWZpY2lhbCBtYW5kYXRlLiwiVGhl IHdvcnN0IEFQSSBpbiB0aGUgaGlzdG9yeSBvZiB0aGUgV1dXLiBEZXNpZ25lZCBmb3IgdGVsY29z IGZvciBzYXRpc2Z5aW5nIHRvZGF5J3MgdGVsY28gYnVzaW5lc3MgKHRoZSAiIndlYnBob25lIGRy ZWFtIiIpLiBCdXQgd29yc2UgdGhhbiB0aGV5IHRoaW5rLiBUZWxjb3Mgc2hvdWxkIG5vdCBkZXNp Z24gYSBKUyBBUEkgZm9yIHRoZSBXM0MgYW5kIFdXVy4gVGhleSBkbyBub3Qga25vdy4iLCoqKiBJ IGRvbid0IHdhbnQgU0RQICoqKiBXZSBkb24ndCB3YW50IHRvIGJlIGZvcmNlZCB0byBPL0EgbW9k ZWw7IFdlIGRvbid0IHdhbnQgdG8gZGVhbCB3aXRoIGJsb2Igc3RyaW5ncywoc3Ryb25nIGRpc2xp a2UpLFllcwpSb2JpbiBSYXltb25kLEF0dGVtcHRpbmcgdG8gaW1wbGVtZW50IGEgcmVmZXJlbmNl IGltcGxlbWVudGF0aW9uIG9mIHRoZSBPcGVuIFBlZXIgUDJQIGNvbW11bmljYXRpb24gc3RhY2sg aW4gSmF2YVNjcmlwdCBhbmQgaGF2ZSB0aGF0IHV0aWxpemUgV2ViUlRDLiwiZ2V0VXNlck1lZGlh PyBzcGluIHVwIGEgcXVpY2sgZGVtbyBpc24ndCBiYWQsIGJ1dCBldmVuIHRoZW4gd2UgbmVlZGVk IHRvIHNoaW0gdGhlIGN1cnJlbnQgYnJvd3NlcnMgYmVjYXVzZSB0aGV5IHdlcmVuJ3QgY29tcGF0 aWJsZSIsIlVuaXZlcnNhbCBmb3JtYXQsIHNpbmdsZSBiaW5kaW5nIHBvaW50IGZvciBzaWduYWxp bmcgYWxsIG1lZGlhLCBhbmQgTy9BIHN0YXRlIG1hY2hpbmUgdGhhdCBkb2Vzbid0IGV4aXN0IGFu ZCB3b3JrcyBjb250cmFyeSB0byBvbmUtc2lkZWQgbmVnb3RpYXRpb25zIGluIE9wZW4gUGVlciIs SG9ycmlibGUuIEFic29sdXRlbHkgaG9ycmlibGUuIEkndmUgc3BlbnQgdGltZSBkcmFmdGluZyB1 cCBleGFjdGx5IHdoYXQgaXMgd3Jvbmcgd2l0aCB0aGlzIGFwcHJvYWNoIGluIGRldGFpbCB3aXRo IHNjZW5hcmlvcy4sSXQncyB0cnVseSBhd2Z1bDogIGJhY2s6IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJheW1vbmQtcnRjd2ViLXdlYnJ0Yy1qcy1vYmotYXBpLXJh dGlvbmFsZS0wMC50eHQsKHN0cm9uZyBkaXNsaWtlKSxTb21ld2hhdC4gQWx3YXlzIHRob3VnaHQg aXQgd2FzIGEgYml0IHdvbmt5IGJ1dCB0aG91Z2h0IHdlIGNvdWxkIHdvcmsgYXJvdW5kIGl0IChh bmQgcGVyaGFwcyBpdCB3YXNzIGdvb2QgZm9yIFNJUCkgYXQgZmlyc3QgYnV0IG5vdyBJIHRoaW5r IHRoZXJlIGlzIG5vIGhvcGUgZm9yIHRoaXMgU0RQIGJhc2VkIEFQSSAoZXZlbiBmb3IgU0lQKS4K Um9tYW4gU2hwb3VudCAsQnJvd3NlciBpbnRlcmZhY2VzIHRvIGEgaG9zdGVkIE1DVSxJbnRlZ3Jh dGlvbiBvZiBXZWIgVUkgd2l0aCByZWFsIHRpbWUgbWVkaWEsU0RQIGludGVyb3AgYmV0d2VlbiB0 aGUgU0RQIHByb2R1Y2VkIGJ5IHRoZSBCcm93c2VyIGFuZCBTRFAgcHJvZHVjZWQgYnkgTUNVLEl0 IGlzIGhvcnJpYmxlIGZvciBpbnRlcm9wIHdpdGggZXh0ZXJuYWwgZW5kIHBvaW50cy4gSXQgYWxz byBwcmV2ZW50cyBhbHRlcm5hdGl2ZSBjYXBhYmlsaXRpZXMgbmVnb3RpYXRpb24gZmxvd3Mgc3Vj aCBhcyBiZXR0ZXIgb2ZmZXIgZ2xhcmUgcmVzb2x1dGlvbiBmbG93cy4sQW4gdW5tYW5hZ2VhYmxl IG1vbnN0ZXIgd2FzIGNyZWF0ZWQgd2hpY2ggY3VycmVudGx5IHN0YXlzIGluIHRoZSB3YXk7IEkg YW0gYWxzbyBzdHJvbmdseSBmb3IgcmVtb3ZpbmcgTy9BIGFuZCBTRFAgZnJvbSB0aGUgQVBJLiBU aGlzIGlzIGEgd3JvbmcgQVBJIHN1cmZhY2UgdGhhdCBkb2VzIG5vdCBwcm92aWRlIHRoZSBuZWNl c3NhcnkgZGVncmVlIG9mIGNvbnRyb2wgZm9yIGJ1aWxkaW5nIFdlYlJUQyBhcHBzLiwoc3Ryb25n IGRpc2xpa2UpLE15IGluaXRpYWwgdmlldyB3YXMgaXQgd2FzIG5vdCBpZGVhbCBidXQgbWFuYWdl YWJsZS4gQXQgdGhpcyBwb2ludCBJIHNlZSB0aGF0IG1haW50ZW5hbmNlIGVmZm9ydCB0aGF0IFNE UCBhbmQgTy9BIHB1dHMgb24ga2VlcGluZyBNQ1UgY29tcGF0aWJsZSB3aXRoIGJyb3dzZXJzIG1h a2VzIGl0IHVuc3VzdGFpbmFibGUuCkJlcm5hcmQgQWJvYmEsUHJvdG90eXBpbmcgb2YgYWNjZXNz aWJpbGl0eSBlbmhhbmNlbWVudHMuLGdVTSBpcyBvazsgY2FuIGxpdmUgd2l0aCBhZGFwdGVyLmpz LCJhPXNzcmMgZGVjbGFyYXRpb24sIGFuZCBvdGhlciBhc3BlY3RzIG9mIFBsYW4gQi4iLEJvdGgg YXJlIHBhaW5mdWwgYW5kIGFydGlmaWNpYWxseSBsaW1pdGluZy4sSSB3ZWxjb21lIFthbl0gZWZm b3J0IHRvIGVuYWJsZSBhcHBsaWNhdGlvbnMgd2hvIGRvbid0IGNhcmUgYWJvdXQgU0RQIHRvIG1p bmltaXplIGl0cyB1c2FnZSBldmVuIGlmIGl0IGlzIG5vdCBlbGltaW5hdGVkIGVudGlyZWx5LiAg ICwoc3Ryb25nIGRpc2xpa2UpLEkgd2FzIGFsd2F5cyB3YXJ5IGJ1dCB0aGUgdmlkZW8gaXNzdWVz IGhhdmUgcHJvdmVkIHRoYXQgdGhlIGN1cnJlbnQgY291cnNlIGlzIHVud29ya2FibGUuClNpbHZp YSBQZmVpZmZlcixXZWIgYXBwbGljYXRpb25zLDEtMSAgd29ya3Mgd2VsbCxoYXZpbmcgdG8gdW5k ZXJzdGFuZCB3aGF0IFNEUCBsaW5lcyBDaHJvbWUvRmlyZWZveCB1bmRlcnN0YW5kIGFuZCBuZWdv dGlhdGU7IGFzIHdlbGwgYXMgd2hhdCB0aGUgU0RQIGxpbmVzIG1lYW4sIkkgZG9uJ3QgbWluZCBT RFAgdXNlZCBieSB0aGUgYnJvd3NlciwgYnV0IHRoZXJlIHNob3VsZCBiZSBzb21lIGV4cGxpY2l0 IGZ1bmN0aW9ucyB0byBtYW5pcHVsYXRlIGl0IHdpdGggdGhlIG1vc3QgY29tbW9uIG5lZWRzIHN1 Y2ggYXMgYDsgSSBoYXZlIG5vIG9waW5pb24gb24gTy9BIHNpbmNlIEkgZG9uJ3Qga25vdyB3aGF0 IHRoZSBhbHRlcm5hdGl2ZSB3b3VsZCBsb29rIGxpa2UiLEkgYW0gcmVhbGx5IGV4Y2l0ZWQgdGhh dCB0aGVyZSBpcyBtb3ZlbWVudCBpbiB0aGlzIHNwYWNlIC4uLiBJJ20gZmVlbGluZyB0aGUgcGFp biwod291bGQgbGlrZSBuaWNlciBpbnRlcmZhY2UgdG8gbWFuaXB1bGF0ZSBTRFApLCJoYWQgbm8g aW5pdGlhbCB2aWV3IC0gaXQgc2VlbWVkIGEgbG9naWNhbCBwaWNrLCBidXQgSSB3YXNuJ3QgZm9y L2FnYWluc3QgaXQiCkpvc8OpIEx1aXMgTWlsbMOhbiAsSW1wbGVtZW50aW5nIGEgSmF2YVNjcmlw dCBTSVAgbGlicmFyeSAoSnNTSVAgLSBqc3NpcC5uZXQgLSksU2ltcGxlc3QgY2FsbCBzZXR1cCAs IlRoZSBmYWN0IHRoYXQgYSBnaXZlbiBzdGltdWx1cyBpbiB0aGUgb2ZmZXJlciAoaWU6IGRpcmVj dGlvbmFsaXR5IGNoYW5nZSksIGV2ZW4gaWYgdHJhbmxhdGVkIGluIHRoZSBTRFAgT2ZmZXIgYXMg J3NlbmRvbmx5JywgJ2luYWN0aXZlJywgJ3JlY3Zvbmx5JywgZG9lcyBub3QgZ2VuZXJhdGUgYSBy ZWFjdGlvbiBpbiB0aGUgYW5zd2VyZXIsIHNvIHRoaXMgbGFzdCBpcyB1bmF3YXJlIG9mIHRoZSBj aGFuZ2VzIChoZW5jZSBjb21tdW5pY2F0aW9uIGl0c2VsZikuIEluIGdlbmVyYWwsIHRoZSBsYWNr IG9mIGNvbnRyb2wgb3ZlciB0aGUgbWVkaWEgYW5kIHRyYW5zcG9ydCBkZXNjcmlwdGlvbiBmcm9t IHRoZSBKYXZhU2NyaXB0IEFQSSwgYm90aCBmcm9tIHRoZSBwb2ludCBvZiB0aGUgcmVxdWVzdG9y LCB3aGVuIG1ha2luZyBhbnkgY2hhbmdlIGFuZCBmcm9tIHRoZSBwb2ludCBvZiByZXF1ZXN0ZWQs IHdoZW4gcmVjZWl2aW5nIHN1Y2ggYSBjaGFuZ2UuICIsIlNEUCBzaG91bGQgYmUgYSBtZXJlIHJl cHJlc2VudGF0aW9uIGZvcm1hdCBhcyB3ZWxsIGFzIEpTT04sIFhNTC4uLiBJIGRvbid0IGZlZWwg bGlrZSBPL0EgaXMgbmVlZGVkIGJ1dCAiImp1c3QiIiBmb3IgaW50ZXJvcGVyYWJpbGl0eSwgc28g aXQgY291bGQganVzdCBleGlzdCBvbiB0aGUgZWRnZXMgd2hlcmUgaW50ZXJvcGVyYWJpbGl0eSBp cyBuZWVkZWQuICIsLEluIGZhdm91ciBvZiB0aGlzIGZsYXZvdXI6IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtcmF5bW9uZC1ydGN3ZWItd2VicnRjLWpzLW9iai1hcGktcmF0aW9uYWxlLTAw LnR4dCxZZXMuIFByb2JsZW1zIGhhdmUgYXJpc2VuIGF0IGltcGxlbWVudGF0aW9uIHRpbWUuIElu aXRpYWxseSBPSyB3aXRoIFNEUApFcmlrIExhZ2Vyd2F5LCJSZWFsdGl2ZWx5IGxhcmdlIGNvbW0g cHJvamVjdHMsIFdlYlJUQyBhcyBhbiBleHRlbnRpb24gdG8gc2VydmljZS4iLCJnZXRVc2VyTWVk aWEsIGJhc2ljIGRlbW9zIGFyZSBzaW1wbGUsIG11bHRpcGxleGluZyBtZWRpYSBzdHJlYW1zIGFu ZCBkb2luZyBmYW5jeSBoYW5kLW9mZnMuIG5vdCBzbyBtdWNoIiwiVGhlIGN1cnJlbnQgTy9BIEFQ SSBkb2VzIG5vdCBwdXQgdGhlIGNvbnRyb2wgaW4gdGhlIGhhbmRzIG9mIEpTIGRldmVsb3BlcnMs IHNvIG1hbnkgb2YgdGhvc2UgZmVhdHVyZXMgYXJlIHNpbXBseSBub3Qgc3VwcG9ydGVkLiIsIlRo ZSBwZW9wbGUgSSBoYXZlIHRhbGtlZCB0bywgZXZlbiBhdCB0aGUgV2ViUlRDIEV4cG8geWVzdGVy ZGF5LCBzb3VuZGVkIHNvbWV3aGF0IHJlbGlldmVkIHdoZW4gSSB0b2xkIHRoZW0gYWJvdXQgdGhp cyBuZXcgSlMgQVBJIG1vZGVsLiBUaGV5IG5lZWQgdG8gc2VlIGl0IGFuZCBwbGF5IHdpdGggaXQg b2J2aW91c2x5LCBidXQgc3VmZmljZSBpdCB0byBzYXkgU0RQIE8vQSBkb2Vzbid0IHNlZW0gbGlr ZSBpdCB3aWxsIHdvcmsgZm9yIG1vc3QgYWR2YW5jZWQgd2ViIGFwcCBkZXZlbG9wZXJzLiIsKzEg dG8gcmUtb3BlbiB0aGUgZGViYXRlIHJlOiBTRFAsKHN0cm9uZyBkaXNsaWtlKSwiWWVzLiBJbml0 aWFsbHkgaXQgc2VlbWVkIGxpa2UgU0RQIG1hZGUgc2Vuc2UsIGFuZCB3b3VsZCB3b3JrIGZvciBt b3N0LiBJIHRoaW5rIGFmdGVyIGhhdmluZyB0byBpbXBsZW1lbnQgdGhlIGN1cnJlbnQgQVBJIHNl dmVyYWwgdGltZXMsIHdlIGFyZSBzZWVpbmcgYXJlYXMgZm9yIGltcHJvdmVtZW50LCBhIG5ldyBt b2RlbCBzZWVtcyB0byBtYWtlIHNlbnNlIG5vdy4iCkFsZXhhbmRyZSBHb3VhaWxsYXJkLCJ0ZWFt IG9mIDUgZGVkaWNhdGVkIHRvIGFsbCBhc3BlY3RzIG9mIHdlYnJ0YyAoY2xpZW50LCBBUEkvU0RL LCBpbmZyYXN0cnVjdHVyZSkiLHRoZSByZWZlcmVuY2UgZGVtbyhzKSBhbmQgYXBwUlRDLiwiQXMg c29vbiBhcyB5b3Ugd2FudCB0byB2ZW50dXJlIGZ1cnRoZXIgdGhhbiBhcHBSVEMsIG9yIHRvIGlt cGxlbWVudCB5b3VyIG93biBpbmZyYXN0cnVjdHVyZSwgbGlmZSBpcyBoYXJkLiBObyBkb2N1bWVu dGF0aW9uLCBldmVyIGNoYW5naW5nIEFQSXMsIG5vdCBmdWxseSBpbXBsZW1lbnRlZCBzdGFuZGFy ZCBhcmUgdGhlIG5vcm0gKGl0J3MgZXhwZWN0ZWQsIG5vbmV0aGVsZXNzIHBhaW5mdWxsKS4gQWxs IHRoZSBkZXRhaWxzIHlvdSB3b3VsZCBoYXZlIHRvIGhhdmUgYWNjZXNzIHRvIHRvbyAobWVkaWEs IGUuZy4gY29kZWMgbGlzdCwgdHJhbnNwb3J0OiBiYW5kd2lkdGggb3B0aW9ucywgSUNFOiB3aGlj aCBpY2UgY2FuZGlkYXRlIGZhaWxlZCwgd2hpY2ggb25lIHdhcyBrZXB0KSAgKnNlZW1zKiB0byBi ZSBhdmFpbGFibGUgb25seSBpbiB0aGUgU0RQLiIsIkkgaG9uZXN0bHkgaGF2ZSBubyBvcGluaW9u LiBJICsxJ2VkIHRoZSB0aHJlYWQgYmVjYXVzZSBJIHdhcyBub3QgaGVyZSBhdCB0aGUgYmVnaW5u aW5nIGFuZCB3YW50ZWQgdG8gaGVhciBib3RoIHNpZGVzLCBhbmQgcmV2aXNpdCB0aGUgcXVldHNp b24gYWZ0ZXIgaGF2aW5nIGRldmVsb3BwZWQgb24gdG9wIG9mIHRoZSBBUEkgZm9yIGEgeWVhci4g V2V0aGVyIGl0IHVzZXMgc2RwIG9yIG5vdCwgaWYgSSBoYWQgYWNjZXNzIHRvIGJhZG53aWR0aCwg Y29kZWMsIElDRSB0aHJvdWdoIGEgbmljZSBBUEksIEkgd291bGRuJ3QgbWluZC4gSSdtIG5vdCBz dXJlIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgdGhlIE8vQSBtZWNoYW5pc20gZW5vdWdoIHRvIGNv bW1lbnQsIGJ1dCBJIGFtIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYW4gaXQgY291bCBkYmUgbWFk ZSBlYXNpZXIgKGRhdGFjaGFubmVsIGxpa2UpIGluIG1hbnkgY2FzZXMsIGluY2x1ZGluZyB0aGUg ZW50cmVwcmlzZSBjYXNlIHdoZXJlIHRoZSBJUHMgYW5kIG90aGVyIG5ldHdvcmsgaW5mb3JtYXRp b25zIGNvdWxkIGJlIGtub3duLiIsKzEgdG8gcmVvcGVuaW5nIHRoZSBkaXNjdXNzaW9uLiwid291 bGQgbGlrZSBleHRlbnNpb24gb2YgdGhlIEFQSSBhdCB0IGhlIEpTIGxldmVsLiBXZXRoZXIgaXQg dXNlcyBzZHAgb3Igbm90IGlzIG5vdCBzbyBpbXBvcnRhbnQuIElmIFNEUCB3YXMgdG8gYmUgY2hv c2VuLCBhIG1vcmUgdmVyYm9zZSBwYXJzZXIgd291bCBkYmUgaGlnaGx5IHdlbGNvbWUuIix3YXMg bm90IGhlcmUgd2hlbiBpdCB3YXMgZmlyc3QgcHJvcG9zZWQuCkFkcmlhbiBHZW9yZ2VzY3UgLCws LCxTRFAgaXMgbm90IHN1Y2ggYSBncmVhdCBpZGVhIHRvIHB1dCBpbiBwcmFjdGljZSBhbmQgW3Nv bWVdIG1heSBhbHNvIHdhbnQgdG8gY29tZSBmb3J3YXJkIHRvIGFkbWl0IHRoZWlyIG1pc3Rha2Uu LChkaXNsaWtlKSAoc3Ryb25nbHk/KSwKTWF0dGhldyBKb3JkYW4sLCwsLCJJbiB0aGUgQXN0ZXJp c2sgcHJvamVjdCwgd2Ugd2VyZSBhYmxlIHRvIHVzZSBvdXIgbGVnYWN5IFNJUCBzdGFjayB0byBl bmFibGUgdmVyeSBiYXNpYyBXZWJSVEMgY29tbXVuaWNhdGlvbiB3aXRoIENocm9tZSBhbmQgRmly ZUZveC4gVGhhdCBzb3VuZHMgbmljZSwgdW50aWwgeW91IHJlYWxpemUgd2UgaGF2ZSB0byBjb250 aW51YWxseSBwcmVmYWNlIHRoYXQgd2l0aCAiInNvbWV0aW1lcyIiLiIsLApCb3NzaWVsIHRoaW9y aWd1ZWwgLCwsLCwiVXNpbmcgdGhlIGN1cnJlbnQgV2ViUlRDIHdlIGhhdmUgbWFuYWdlZCB0byAq ZWFzaWx5KiBidWlsZCBhbG1vc3QgYWxsIGtpbmQgb2YgYXBwbGljYXRpb25zOiBjbGljay10by1j YWxsLCBTSVAvSU1TIGNsaWVudHMsIGdhdGV3YXlzIHRvIFBTVE4sIE1DVXMsIFRlbGVtZWRpY2lu ZSBzeXN0ZW1zLi4uYW5kIGhhdmVuJ3Qgc2VlbiBhbnkgbWFqb3IgaXNzdWUiLChpdCdzIGdvb2Qp LApBbmRyZXcgSHV0dG9uLCxTSVAgaW50ZXJ3b3JraW5nIGhhcyBiZWVuIHJlbGF0aXZlbHkgc3Ry YWlnaHQgZm9yd2FyZC4sLFRoZSBjdXJyZW50IFNEUCBiYXNlZCBBUEkgaGFzIHdvcmtlZCB3ZWxs IGZvciB1cyBidXQgd2UgZG8gaGF2ZSBhIGxvdCBvZiBleHBlcnRpc2UgaW4gU0RQIG1hbmlwdWxh dGlvbi4gVGhlIEFQSSBkb2VzIG5vdCByZXN0cmljdCB0byBvbmx5IHVzaW5nIGFuIE8vQSBtb2Rl bCBidXQgZG9lcyBtYWtlIGludGVyd29ya2luZyB3aXRoIE8vQSBlYXN5IHdoaWNoIGlzIG5lZWRl ZC4gRm9yIHN1cmUgSSBhZ3JlZSBTRFAgaXMgdWdseSBhbmQgYmVsaWV2ZSB0aGF0IFNEUCBtYW5p cHVsYXRpb24gc2hvdWxkIGJlIHBlcmZvbWVkIHVzaW5nIEFQSSBjb25zdHJhaW50cyByYXRoZXIg dGhlbiBkaXJlY3QgU0RQIG1hbmlwdWxhdGlvbi4gSSB3YW50IHRvIHNlZSBWMSBjb21wbGV0ZSB3 aXRob3V0IGFkZGluZyB0b28gbXVjaCBTRFAgY29tcGxleGl0eSBiZWZvcmUgbWFraW5nIGEgZGVj aXNpb24gb24gZnV0dXJlIGRpcmVjdGlvbi4sTGV0J3MgY29uY2VudHJhdGUgb24gbWFraW5nIHN1 cmUgYWxsIHRob3NlIGlubm92YXRpdmUgYXBwcyBhbHJlYWR5IHdyaXR0ZW4gZGVwbG95YWJsZSBi ZWZvcmUgd2Ugc3RhcnQgdHJ5aW5nIHRvIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cyBvZiB0aGUg bWVnYSBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzLiwoZ29vZCBmb3IgMS4wKSwKUGhpbGlwcCBIYW5j a2UsInhtcHAsIG1hcHBpbmcgc2RwIHRvIGppbmdsZSBhbmQgdmljZSB2ZXJzYS4gYnJvd3Nlciwg bmF0aXZlICsgYW5kcm9pZCIsLCJlYXJseSB0cmFuc3BvcnQgd2FybXVwLiBIYWQgdG8gY29tZSB1 cCB3aXRoIGEgcHJhbnN3ZXIgaGFjayBiZWNhdXNlIHRoZSBhZGRpY2VjYW5kaWRhdGUgYXBpIGRv ZXNuJ3QgdXNlIGVub3VnaCBzZHAuIEFsc28sIGkgYW0gZnJlcXVlbnRseSBoaXR0aW5nIGltcGxl bWVudGF0aW9uIGJ1Z3MgYmVjYXVzZSBvZiBtYW5nbGluZyB0aGUgc2RwIGFsb3QsIGJ1dCB0aGF0 IGlzIG5vdCB0aGUgZmF1bHQgb2YgU0RQLiIsIm8vYSBpcyBmaW5lIGZvciBzZXR0aW5nIHVwICgx LTEpIGNhbGxzLiBUaGluZ3MgbGlrZSBtdXRlIHNob3VsZCBub3QgcmVxdWlyZSBPL0EsIG5vciBz aG91bGQgYWRkaW5nIGEgcmVtb3RlIHN0cmVhbSBkby4gU0RQIGlzIHVnbHkgYW5kIGNvbXBsZXgs IHRyeWluZyB0byBleHByZXNzIHN0cnVjdHVyZWQgZGF0YSBpbiBhIHBsYWludGV4dCBmb3JtYXQu IEppbmdsZXMgeG1sIGlzbid0IG11Y2ggYmV0dGVyIGhvd2V2ZXIsIGJ1dCBpdCBoYXMgYSBtdWNo IGJldHRlciBzZXBhcmF0aW9uIG9mIG1lZGlhIGFuZCB0cmFuc3BvcnQuIiwsKHVnbHkgYW5kIGNv bXBsZXg7IGZpbmUgZm9yIHNpbXBsZSBjYWxscyksIm5vLiBJIGtuZXcgU0RQIHdhcyBnb2luZyB0 byBiZSBwYWluZnVsLiBIb3dldmVyLCBpdCBzZWVtZWQgbGlrZSBwcm9ncmVzcyBvdmVyIHRoaW5n cyBsaWtlIGFkb2JlcyBuZXRjb25uZWN0aW9uIGFwaSBpbiBmbGFzaCIKR2F2aW4gTGxld2VsbHlu LCJKUyBsaWJyYXJ5IGVuYWJsaW5nIG1lZGlhIGNhbGxzLCBJTSwgZGF0YSB0cmFuc2ZlciAmIHBy ZXNlbmNlIG92ZXIgb3VyIG93biBTSVAgc2lnbmFsbGluZyBpbmZyYXN0cnVjdHVyZSwgaW5jbHVk aW5nIFBTVE4gYnJlYWtvdXQgYW5kIGJpbGxpbmciLERlbW8gdXAgYW5kIHJ1bm5pbmcgc3VycHJp c2luZ2x5IHF1aWNrbHksIk1vc3RseSBpbmNvbXBhdGliaWxpdHkgcHJvYmxlbXMgYmV0d2VlbiBp bXBsZW1lbnRhdGlvbnMsIGFzIHRoZXkncmUgYWxsIGF0IHRoZSB0ZWV0aGluZyBzdGFnZSBhdG0u ICBPZnRlbiBzZWVtcyB0byBiZSBJQ0UtcmVsYXRlZC4iLCJJdCdzIHdvcmtlZCB3ZWxsIGZvciB1 cywgc2luY2Ugd2UncmUgZXhwZXJpZW5jZWQgd2l0aCBTSVAsIGFuZCBoYXZlbid0IGhhZCB0byBt YW5nbGUgdGhlIFNEUCBtdWNoLiAgSXQgZG9lcyBmZWVsIGEgYml0IG9kZCB0byB1c2UgaXQgYXMg YSBjb250cm9sIHN1cmZhY2UsIGJ1dCBJIHRoaW5rIHdlJ3JlIGJldHRlciBvZmYgc3RpY2tpbmcg d2l0aCBpdCBpZiB0aGUgYWx0ZXJuYXRpdmUgd291bGQgZGVsYXkgdGhlIHNwZWMgc2lnbmlmaWNh bnRseS4iLCwoYSBiaXQgb2RkOyAgZmluZSBmb3Igc2ltcGxlIGNhbGxzOyBnb29kIGZvciAxLjAp LApUaW0gUGFudG9uLCJDcmVhdGluZyBhIHNpbXBsZSBqcXVlcnkgQVBJIHRoYXQgbGV0cyBqYXZh c2NyaXB0IGRldnMgdGFsayB0byBvdXIgaW5mcmFzdHV0dXJlIGFuZCBtYWtlIGNhbGxzIGluIGEg Y291cGxlIG9mIGxpbmVzLiBGYWxsYmFjayB0byBmbGFzaCBpZiB3ZWJSVEMgbm90IGF2YWlsYWJs ZSwgQ3JlYXRpbmcgb3BlbnNvdXJjZSBpbnRlcm9wZXJhYmxlIGNsaWVudCBjb2RlIGZvciBpT1Ms IGFuZHJvaWQsIGphdmEuICIsIldpcmUgcHJvdG9jb2xzIGFyZSB3ZWxsIGRlZmluZWQsIHdyaXRp bmcgZ2F0ZXdheSBvciBjbGllbnQgY29kZSBmcm9tIHNjcmF0Y2ggdG8gY29uc3VtZSB3ZWJSVEMg bWVkaWEgaXMgcG9zc2libGUganVzdCB3aXRoIGN1cnJlbnQgZG9jdW1lbnRhdGlvbi4iLElsbCBk ZWZpbmVkIFNEUCAtIG5vbi1leGlzdGFudCBlcnJvciBtZXNzYWdlcyB3aGVuIHNvbWV0aGluZyBn b2VzIHdyb25nLiBDcmVhdGluZyBpbnRlcm9wZXJhYmxlIFNEUCBpcyBhbiBhbG1vc3QgZW5kbGVz cyB0cmlhbC1hbmQtZXJyb3IgY3ljbGUuLCJTRFAgbWFrZXMgYSBwb29yIEFQSSBzdXJmYWNlLCBp dCBpcyBhbWJpZ2lvdXMsIGJyaXR0bGUgYW5kIGluZmxleGlibGUuIE8vQSBoYXNuJ3QgbGltaXRl ZCB1cyBzbyBmYXIsIGJ1dCBpdCBpcyBhbG1vc3QgaW5leHBsaWNhYmxlIHRvIHdlYiBkZXZlbG9w ZXJzLiIsIldoZW4gd2UgaW1wbGVtZW50ZWQgRFRMUyBzdXBwb3J0IChmb3IgZmlyZWZveCksIEkg c3BlbnQgbG9uZ2VyIG9uIGdldHRpbmcgdGhlIGNvcnJlY3QgU0RQIHRoYW4gSSBkaWQgb24gdGhl IGNyeXB0byBpbnRlZ3JhdGlvbi4gIiwiU3Ryb25nIGRpc2xpa2UsIGJ1dCBpdCBpcyBzdXJ2aXZh YmxlIGZvciAxLjAgaWYgd2Ugc3RvcCBtZXNzaW5nIHdpdGggaXQuIiwiU29tZXdoYXQsIG15IGlu aXRpYWwgZmVlbGluZyB3YXMgdGhhdCBTRFAgd2FzIHRoZSB3cm9uZyBzb2x1dGlvbiwgdGhlbiBJ IHdhcyBsYXJnZWx5IGNvbnZpbmNlZCB0aGF0IGEgZ29vZCBhIGNvbnN0cmFpbnRzIEFQSSBjb3Vw bGVkIHdpdGggYSBkZXNjcmlwdGlvbiBvZiByZWxldmFudCBTRFAgd291bGQgYmUgYW4gYWRlcXVh dGUgd29yayBhcm91bmQuIEknbSBub3cgc2lnbmlmaWNhbnRseSBsZXNzIGNvbnZpbmNlZCB0aGF0 IGVpdGhlciBpcyBwb3NzaWJsZS4iCkNocmlzdG9waCBEb3JuLENvbXBsZXRlbHkgbmV3IHRvIFJU Qy4gU3RhcnRlZCB3aXRoIGJ1aWxkaW5nIGV4YW1wbGVzLiBXaWxsIGhlbHAgYnVpbGQgY3Jvc3Mt cGxhdGZvcm0gY29tbXVuaWNhdGlvbiBzZXJ2aWNlLixHZXR0aW5nIGV4YW1wbGVzIHJ1bm5pbmcg cXVpY2tseSBhbmQgYmVpbmcgYWJsZSB0byB0ZXN0IHdpdGggdHdvIHBlZXJzIG9uIHNhbWUgYnJv d3NlciBwYWdlLiwiTGVhcm5pbmcgYWxsIHRoZSBjb25jZXB0cyAoSUNFLCBTRFAsIHNpZ25hbGlu ZykgdG8gdW5kZXJzdGFuZCB3aGF0IHRoZSBBUEkgYWN0dWFsbHkgZG9lcyB0byB1bmRlcnN0YW5k IHdoYXQgY2FuIGJlIGRvbmUuIFRydWUgY2FwYWJpbGl0eSBvZiBBUEkgaXMgbm90IGNsZWFyIGJ5 IGxvb2tpbmcgYXQgbWV0aG9kcy9ldmVudHMuIERlYWxpbmcgd2l0aCBtb2RpZnlpbmcgU0RQIHRv IGRvIGFueXRoaW5nIG5vbi1zdGFuZGFyZC4iLFNlZW1zIHRvIGJlIGEgd2lyZSBwcm90b2NvbC4g Tm90IHNvbWV0aGluZyBhIGRldmVsb3BlciB3YW50cyB0byBoYXZlIHRvIGRlYWwgd2l0aC4gTmVl ZCB0byB3cml0ZSBvd24gYWJzdHJhY3Rpb24gbGF5ZXIgdG8gbW9kaWZ5IGFueXRoaW5nIGJleW9u ZCB2ZXJ5IGJhc2ljIHVzZS1jYXNlcy4gTG9va3MgbGlrZSB0aGVyZSB3aWxsIGJlIGEgbG90IG9m IGR1cGxpY2F0aW9uIGluIHdvcmsgZGVhbGluZyB3aXRoIFNEUCBtb2RpZmljYXRpb24uLCxkb24n dCBsaWtlIHZlcnkgbXVjaCBhcyBhbiBBUEkgSSBuZWVkIHRvIGRlYWwgd2l0aDsgY2hhbmdlIG5v dyB0byByZW1vdmUgU0RQIGJlZm9yZSBpdCBpcyB0b28gbGF0ZSwKR3VzdGF2byBHYXJjw61hLEJ1 aWxkaW5nIHZpZGVvY29uZmVyZW5jZSBwbGF0Zm9ybSxnZXRVc2VyTWVkaWEgYW5kIHF1aWNrIGJh c2ljIGRlbW8uICBQU1ROIGludGVyY29ubmVjdGlvbiB3YXMgZWFzeSB0byBpbXBsZW1lbnQgKGJl Y2F1c2UgaXQgaXMgYSB2ZXJ5IGJhc2ljIHVzZSBjYXNlIGFuZCBpdCBpcyBvbmx5IGF1ZGlvKS4s IkZpbmRpbmcgd2hhdCBpcyB3cm9uZyBpbiBteSBTRFAgd2hlbiBvbmUgYnJvd3NlciBzdG9wIGJl aGF2aW5nIGFzIGV4cGVjdGVkIChub3QgYWNjZXB0aW5nIGNhbmRpZGF0ZXMsIG5vdCBzZW5kaW5n IFBMSXMuLi4pLiAgRmluZGluZyBkb2N1bWVudGF0aW9uIGFuZCBkaXNjb3ZlcmluZyBuZXcgbWVk aWEgY29uc3RyYWludHMuICAgSGFja3MgdG8gU0RQIChpbmFjdGl2ZSwgYT1iOkFTLCBjcnlwdG8p LiAgIHJlLU9mZmVyL0Fuc3dlciBuZXZlciB3b3Jrcy4gIERvbid0IGhhdmUgYW4gdW5kZXJzdGFu ZGluZyBvbiBob3cgdGhhdCBBUEkgY2FuIGV2b2x2ZSB0byBzdXBwb3J0IHNpbXVsY2FzdCwgbW9k aWZ5aW5nIGJpdHJhdGUgZHluYW1pY2FsbHksIG1vZGlmeWluZyBsaXN0IG9mIGNvZGVjcy4uLiki LFRoZSBiZW5lZml0IGlzIGxvdyBmb3IgdGhlIHByb2JsZW1zIGl0IGJyaW5ncyB1cC4sIlRoZXJl IGFyZSBvbmx5IHR3byByZWFzb25hYmxlIGFwcHJvYWNoZXMsIGNoYW5naW5nIHRoZSBBUEkgbm93 IG9yIGNoYW5naW5nIGl0IGluIGEgeWVhci4KCisxIHRvIHJlLW9wZW4gdGhlIGRlYmF0ZSByZTog U0RQLiAgIiwiU3Ryb25nIGRpc2xpa2UsIG9ubHkgYWNjZXB0YWJsZSBmb3IgMS4wIGlmIHdlIHN0 b3AgdHJ5aW5nIHRvIGFkZCBmZWF0dXJlcyBhbmQgdGhlcmUgaXMgYSBzdHJvbmcgY29tbWl0bWVu dCB0byBjaGFuZ2UgaXQgbGF0ZXIiLCJTb21ld2hhdCwgSSBuZXZlciBsaWtlZCBTRFAgYW5kIE8v QSBhIGxvdCBidXQgd2FzIG5vdCBleHBlY3RpbmcgdGhhdCBpdCBjb3VsZCBiZWNvbWUgc28gcHJv YmxlbWF0aWMuIgpMYW5jZSBTdG91dCAobGFuY2VAYW5keWV0Lm5ldCksIlRhbGt5LmlvLCBTaW1w bGVXZWJSVEMsIFhNUFAgb3ZlciBXZWJTb2NrZXQgSlMgbGlicmFyeSAoc3RhbnphLmlvKSIsIlZl cnkgZWFzeSB0byBnZXQgaW5pdGlhbCAxLTEgdmlkZW8gY2FsbHMgYW5kIGdyb3VwIG1lc2ggY2Fs bHMgdG8gd29yayB3aXRoIHNvY2tldC5pbywgYWZ0ZXIgc29tZSBjcm9zcy1icm93c2VyIGFwaSBz bW9vdGhpbmciLCJUaGUgY2xhaW1zIG9mIHVzaW5nIFhNUFAgSmluZ2xlIGZvciBzaWduYWxsaW5n IGJlY2F1c2UgYW55IHNpZ25hbGxpbmcgcHJvdG9jb2wgaXMgYWxsb3dlZCByaW5nIGhvbGxvdyAt LSB0cmFuc2xhdGluZyB0aGUgU0RQIGlzIHJlcXVpcmVkLCB3aGljaCBpcyBhIGhhY2t5LCBmcmFn aWxlLCBhbmQgbG9zc3kgcHJvY2Vzcy4gSXQncyBkb2FibGUsIGJ1dCBjb25zdGFudCB2aWdpbGFu Y2UgaXMgbmVlZGVkIHRvIGVuc3VyZSBpdCBrZWVwcyB3b3JraW5nLCBhbmQgc29tZSBuZXcgZmVh dHVyZXMgZG9uJ3QgdHJhbnNsYXRlIGF0IGFsbCB5ZXQgKEJVTkRMRSwgc3NyYywgZXRjKS4gRmln dXJpbmcgb3V0IGluY29uc2lzdGVuY2llcyBiZXR3ZWVuIHdoYXQgRkYgYW5kIENocm9tZSBleHBl Y3QgaW4gdGhlIFNEUCAoRFRMUywgZXRjKS4iLCJJdCBmZWVscyB0byBvbmx5IGhhdmUgYmVlbiBw b3RlbnRpYWxseSB1c2VmdWwgZm9yIFNJUCBkZXZlbG9wZXJzL2ludGVncmF0aW9uLCBidXQgdGhh dCBpcyB0b28gZmFyIHJlbW92ZWQgZnJvbSB0aGUgJ1dlYicgcGFydCBvZiBXZWJSVEMgdG8gYmUg dXNlZnVsIGZvciBub24tU0lQL3RlbGVwaG9ueSBkZXZzLiBTRFAgaXMgdG9vIG1hbGxlYWJsZSBv ZiBhIGZvcm1hdCB0byBiZSByZWxpYWJsZSBhcyBhbiBBUEkuIEF0IHRoZSB2ZXJ5IGxlYXN0IGdp dmUgdXMgYSBwYXJzZWQgdmVyc2lvbiBvZiB0aGUgU0RQIGJsb2IsIG90aGVyd2lzZSB0aGVyZSB3 aWxsIGJlIGxvdHMgb2YgYnJva2VuIFNEUC1KU09OIHBhcnNlcnMuIiwsU3Ryb25nIGRpc2xpa2Ug Zm9yIFNEUCBhcyBmaW5hbCBBUEkuIFRoZSAnbm8gcGxhbicgcGxhbiBzb3VuZHMgbGlrZSB0aGUg YmVzdCBmb3J3YXJkIG1vdmluZyBjb21wcm9taXNlLE5vCldvbGZnYW5nIEJlY2sscnRjLmsudnUg YSBkZW1vbnN0cmF0b3IgdXNpbmcgM3JkIHBhcnR5IGF1dGguLCJiYXNpYyBjYWxsLCBOQVQgdHJh dmVyc2FsIixFdmVuIGNvbW1vbiBmdW5jdGlvbnMgbGlrZSBtdXRpbmcgYSBjYWxsIHJlcXVpcmUg U0RQIHBhcnNpbmcgYW5kIG1hbmlwdWxhdGlvbi4gLCJTRFAgc2hvdWxkIGF0IGxlYXN0IGJlIGVu Y2Fwc3VsYXRlZCB3aXRoIGFuIEFQSSBmb3IgY29tbW9uIG9wZXJhdGlvbnMsIGxpa2UgJ211dGUn LiBJbiBnZW5lcmFsLCB0aGUgaW50ZXJvcGVyYWJpbGl0eSBhcmd1bWVudCBmb3IgU0RQIGlzIHdl YWtlciB0aGFuIGV4cGVjdGVkIC0tIHNlZSBkYXRhIGNoYW5uZWwgY29udGVudCBuZWdvdGF0aW9u LiIsLFdlYiBkZXZlbG9wZXJzIHNob3VsZCBub3QgaGF2ZSB0byBkZWFsIHdpdGggU0RQLCJObywg YWxsIG15IGNvbmNlcm5zIHdlcmUgY29uZmlybWVkLiBIb3dldmVyLCB0aGUgSlNFUCBwcm9wb3Nh bCBoYXMgcG90ZW50aWFsIGZvciBpbXByb3ZlbWVudCAod2hpY2ggUk9BUCBkaWRuJ3QgaGF2ZSku IgpEbWl0cnkgU29iaW5vdixBZGRpbmcgc3VwcG9ydCBvZiBXZWJSVEMgY2xpZW50cyB0byBBZGRM aXZlLmNvbSB3ZWJjb25mZXJlbmNpbmcgcGxhdGZvcm0sMi11c2VyIGJhc2ljIGNvbmZlcmVuY2Ug d2l0aCBhdWRpby92aWRlbywiU0RQIG1hbmlwdWxhdGlvbnMgYW5kIGdlbmVyYXRpb24gaW4gSmF2 YVNjcmlwdC4gV2UgZGlkbid0IG9yaWdpbmFsbHkgdXNlIG9mZmVyL2Fuc3dlciBhbmQgU0RQIGlu IG91ciBwcm9kdWN0LCBzbyBub3cgd2UgaGF2ZSB0byBnZW5lcmF0ZSBTRFAgYW5kIHNpbXVsYXRl IG9mZmVyL2Fuc3dlciBmb3IgV2ViUlRDIEFQSSBjb21wbGV0ZWx5IGluIEphdmFTY3JpcHQgZnJv bSBkYXRhIHdlIGdvdCBmcm9tIG91ciBjdXN0b20gc2lnbmFsaW5nIHByb3RvY29sLiBJdCBpcyBu b3QgY2xlYXIgaG93IHRvIG11dGUgc2VwYXJhdGUgbWVkaWEgc3RyZWFtcyBjb3JyZWN0bHkuIEFu ZCBpdCByZXF1aXJlcyBtb2RpZmljYXRpb25zIG9mIFNEUCBhbmQgb2ZmZXIvYW5zd2VyIHJvdW5k IGFnYWluLiBTaW1pbGFyIGNvbmNlcm5zIGFib3V0IGFkZGluZy9yZW1vdmluZyBtZWRpYSBzdHJl YW1zIHRvIGV4aXNpbmcgUGVlckNvbm5lY3Rpb24uIiwiU0RQIGlzIGEgYmFkIGNob2ljZSBmb3Ig QVBJLCBiZWNhdXNlIGl0IHJlcXVpcmVzIGxvdHMgb2YgcGFyc2luZyBhbmQgbW9kaWZpY2F0aW9u cyB0byBhY2hpZXZlIG5vbi10eXBpY2FsIHVzZSBjYXNlcy4gTy9BIGlzIG5vdCBuZWVkZWQgaW4g YWxsIHVzZSBjYXNlcywgYnV0IGhhdmluZyB0aGlzIGlzIG5vdCBhIGJpZyBwcm9ibGVtLiIsLFN0 cm9uZyBkaXNsaWtlIGZvciBTRFAsTm8KSmVzw7pzIExlZ2Fuw6lzIENvbWJhcnJvIChwaXJhbm5h QGdtYWlsLmNvbSksIldlYlAyUC5pbywgYW4gYXBwbGljYXRpb24tYWdub3N0aWMgZnJhbWV3b3Jr IHRvIGVhc2lseSBkZXZlbG9wIFAyUCBhcHBsaWNhdGlvbnMgb24gSFRNTDUKU2hhcmVJdCEsIGEg c2VydmVybGVzcyBhbmQgcHVyZSBjbGllbnQtc2lkZSBQMlAgZmlsZXNoYXJpbmcgYXBwbGljYXRp b24gaW4gSFRNTDUgYW5kIEphdmFzY3JpcHQiLCwiQ29udGludW91cyBjaGFuZ2VzIG9uIHRoZSBB UEksIGxhY2sgb2YgaW50ZXJvcGVyYXRpYmlsaXR5IGFuZCBub3QgYWxsaWduZW1lbnQgdG8gdGhl IHNwZWNpZmljYXRpb24sIGFsc28gYWZ0ZXIgcmVtb3ZpbmcgcHJlZml4ZXMuIERlZmluaXRlbHkg aXQgaGFzIGJlZW4gZG9uZSB0b28gZWFybHkgYnkgYnJvd3NlciBpbXBsZW1lbnRlcnMiLCJTaG91 bGQgYmUgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsIHRoYXQgaXQncyBzdHJhbmdlIGZvciBhcHBs aWNhdGlvbnMgdGhhdCBvbmx5IHJlcXVpcmUgRGF0YUNoYW5uZWxzIGFuZCBkb24ndCBuZWVkIHRv IGRvIG5lZ290aWF0aW9uLCBhbmQgaWYgcG9zc2libGUsIE8vQSBzaG91bGRuJ3QgYmUgbmVlZGVk IiwsIkkgZG9uJ3QgdG90YWxseSBkaXNhZ3JlZSBPL0EgaWYgdGhlcmUncyBubyBiZXR0ZXIgYWx0 ZXJuYXRpdmUsIGJ1dCB0aGVyZSBzaG91bGQgYmUgYSBoaWdoZXIgbGV2ZWwgYWx0ZXJuYXRpdmUg dG8gU0RQLCBhbmQgYWxzbyBzaG91bGQgYWxsb3cgdG8gaW50ZXJjaGFuZ2UgbGVzcyB2ZXJib3Nl IG1lc3NhZ2UgKFNEUHMgY2FuIGdldCB0byBiZSBjcmF6eSBiaWcgYWxzbyBpbiB0aGUgbW9zdCBz aW1wbGUgc2NlbmFyaW9zKSIsIk5vdCByZWFsbHksIEkgdGhvdWdoIGl0IHdhcyBhIHN0cmFuZ2Ug ZGVjaXNpb24gYnV0IHRob3VnaCBpdCB3YXMgdGhlIG9ubHkgb25lLCBhbmQgYWxzbyBhIHN0YW5k YXJkIG9uZSwgc28gSSBhY2NlcHRlZCBpdC4gTm93IEkgdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGJl dHRlciBvcHRpb25zIHRoYXQgaGlkZSBzbyBtdWNoIGNvbXBsZXhpdGllcyBhbmQgYWxzbyBkb24n dCByZXF1aXJpbmcgc28gbXVjaCBiYW5kLXdpZHRoIHdhc3RlLiIKSmFuIExlbGlzLCBTbWFsbCB2 aWRlby9hdWRpby9kYXRhIGNvbmZlcmVuY2VzIChwYWxhdmEudHYpLCJIZWxsbyB3b3JsZC9kZW1v IGFwcGxpY2F0aW9ucy4gQ29ubmVjdGlvbiBpdHNlbGYsIG9uY2UgaXQgaGFzIGJlZW4gZXN0YWJs aXNoZWQuIiwiQnJvd3NlciBpbnRlcm9wLiBBbHNvLCB0aGUgY3VycmVudCBicm93c2VyIGltcGxl bWVudGF0aW9ucyBhcmUgc3RpbGwgdmVyeSBidWdneSB3aGVuIGl0IGNvbWVzIHRvIGFsbCB0aGUg ZGV0YWlscy4iLCJXb3VsZCBub3QgbWluZCBoYXZpbmcgdG8gdXNlIHRoZSBTRFAgYmFzZWQgQVBJ LiBCZXR0ZXIgSlMgaW50ZXJmYWNlcyB3aWxsIGJlIGRldmVsb3BlZCBieSB0aGUgSlMgY29tbXVu aXR5LiBPbiB0aGUgb3RoZXIgaGFuZCwgd2UgZG9uJ3QgaGF2ZSBhIHByb2JsZW0gc2hpZnRpbmcg dG8gYW5vdGhlciBBUEkgbm93L3Nvb24vbGF0ZXIuIEhhZCBzb21lIHByb2JsZW1zIHdpdGggTy9B LCBidXQgSSBhbSBub3QgY29udmluY2VkIHRoYXQgdGhlIHRoZSBnZW5lcmFsIGFwcHJvYWNoIG5l ZWRzIHRvIGNoYW5nZS4iLCwiQSBKUyBBUEkgd291bGQgYmUgbmljZSwgYnV0IGNvdWxkIGxpdmUg d2l0aCBoYXZpbmcgdG8gZGVhbCB3aXRoIFNEUC4gTm8gc3Ryb25nIG9waW5pb24gb24gTy9BLiIs ClNhw7psIEliYXJyYSBDb3JyZXRnw6ksU0lQIG92ZXIgV2ViU29ja2V0cyxBIChyZWFsbHkpIHNp bXBsZSBjYWxsZmxvdywiQW55dGhpbmcgcmVsYXRlZCB0byBTRFAgbWFuaXB1bGF0aW9uLCBzaW5j ZSBpdCdzIHRyZWF0ZWQgYXMgYW4gb3BhcXVlIGJsb2IuIiwiVXNpbmcgU0RQIG9yIE8vQSBhcyB0 aGUgQVBJIGlzIHRlcnJpYmx5IGxpbWl0aW5nLiBBIGxvd2VyIGxldmVsIEFQSSBhbGxvd3MgZm9y IFNEUCB0byBiZSBidWlsdCBvbiB0b3AsIGJ1dCB0aGUgb3RoZXIgd2F5IGFyb3VuZCwgdGhpbmdz IGRvbid0IHJlYWxseSB3b3JrIHdlbGwuIiwsU3Ryb25nIGRpc2xpa2UgZm9yIFNEUC4sIlllcy4g SW4gdGhlIGJlZ2lubmluZyBJIHRob3VnaHQgaXQgd291bGQgbWFrZSBnZXR0aW5nIFNJUCB3b3Jr aW5nIGVhc2llciwgYnV0IGl0IHR1cm5lZCBvdXQgdG8gbWFrZSBpdCByZWFsbHkgY29tcGxleCB0 byBzdXBwb3J0IHZlcnkgYmFzaWMgZmVhdHVyZXMuIg== --001a11c39d18038e6604e1de7955-- From ibc@aliax.net Fri Jul 19 08:04:19 2013 Return-Path: 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 5393711E82E0 for ; Fri, 19 Jul 2013 08:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=-1.183, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 O75hTgsQ+-7E for ; Fri, 19 Jul 2013 08:04:14 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 79F5F11E82BD for ; Fri, 19 Jul 2013 08:03:58 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id hu16so4230768qab.15 for ; Fri, 19 Jul 2013 08:03:58 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=8G/eIOxQF/5oBWdubAIGXBj93TfL1OrW6QdYGFALJn0=; b=a09IEghe1Z0nGv7mCIu918oZeb6Jg8mGC0s/R+TuMOgcvfHIAc0NxrvutGWsBzwdLf Vo4Qj7pyBuH2/96312XP+9qhyCzbR/0dLBSSlFnswI02VYrNB2Hz5ijx4/pVWPNWer06 TGnNpBC0tEtDXNo1wSf6SrMmiVTpyEBNfN71WKz9prVya/KBh/Cy1er4LQ/rKTAP6U+1 GBUIMtWpqLMhApDf5s3Cx75QJhZ3h4tPcEwbWQxm02tRwgMxxyyZ2XxtPJZkPa4+Qy+P 31/8bLow1t5m1X1BqxzzlPejqJeW/0+5RG/ztyYVEyqSXhrt8eSE4pn3wruGSZTMeBFY 5w3g== X-Received: by 10.229.112.6 with SMTP id u6mr4097065qcp.47.1374246237605; Fri, 19 Jul 2013 08:03:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Fri, 19 Jul 2013 08:03:37 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 19 Jul 2013 17:03:37 +0200 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkpkGeCZYmc/CrAO28t8/PuDhILmI1FjeQpyC0JS84ll/c0c8trQ+QP3Om264XoSNGYw+xN Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:04:19 -0000 2013/7/19 Cullen Jennings : > Folks wanted to sort out how mindless works fist before getting to theses= smaller details Hi Cullen, All these "smaller details" are in fact issues and problems we don't need. Issues not needed at all in WebRTC, issues that WebRTC developers and vendors should NOT care about. If those "smaller details" do exist is due the mandate of SDP. And all the time the WG (or WGs) will spent "fixing/defining" them is just wasted time, since nothing useful is being done for WebRTC by "defining" those "minor details". Regards. -- I=C3=B1aki Baz Castillo From cowwoc@bbs.darktech.org Fri Jul 19 08:54:33 2013 Return-Path: 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 3FB2811E8137 for ; Fri, 19 Jul 2013 08:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.941 X-Spam-Level: X-Spam-Status: No, score=-5.941 tagged_above=-999 required=5 tests=[AWL=-2.342, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 eSf0ekyE4g3i for ; Fri, 19 Jul 2013 08:54:27 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 570B111E812C for ; Fri, 19 Jul 2013 08:54:27 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so4230793qae.20 for ; Fri, 19 Jul 2013 08:54:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=TCTwFH9C+L/gMpRRgvOesN0ULkSTssA12cFxgYRinFY=; b=ReR8ifjtjrqJEA9FcOguvjNwUtRTMtq3AKcgLNbcMJdydVodjHLEaWyff9U1NaH2d1 Rur3JX7AVtxYtGFRz2jtApvrSnHel19nDhixP0PvEAW5IueyiZ3WS/rFjIbBJwG+knsG D+T79JBwSJA1BG69W8qMRwXRsY+xJGtU5bY8dodUXG/kflvHReXwsY1sh1telvhOt3eW CLwkSw681b7LpR6VKEVoVAzN5gIrxIqsrktcHxiGMe4xr5d+xMPP4pQOt6iUf9d8hfH6 eyxwvljO8wUG2bFFWXCfRNjm4UhZSoBitMAkRTILkDeOtvDhfxjJ3CibaCC/63aLLViA pXbg== X-Received: by 10.224.53.136 with SMTP id m8mr8900863qag.63.1374249266690; Fri, 19 Jul 2013 08:54:26 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id y4sm23361304qai.5.2013.07.19.08.54.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 08:54:25 -0700 (PDT) Message-ID: <51E96123.5070301@bbs.darktech.org> Date: Fri, 19 Jul 2013 11:54:11 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Cullen Jennings References: <51DC3644.4020107@bbs.darktech.org> <51DC8445.2030902@bbs.darktech.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk4gWir/dG5N5Z6iBEooTe5ULV30jSwwdxKFqX45+PULL9rRjy5XiQxqt7gk7DB+IJPB3/w Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Locus of API discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:54:33 -0000 On 19/07/2013 10:24 AM, Cullen Jennings wrote: > On Jul 9, 2013, at 2:44 PM, cowwoc wrote: > >> Three weeks ago I posted a summary of discussion points that came up in the WebRTC World conference (most of which had to do with the WebRTC API). To date, I have not received a reply from any of the people you have listed. I am unable to gather the necessary momentum to turn these points into action items without your help. I was/am frustrated that the spec editors and vendors are responsible to engage the community on these matters, but did not. I hope this clarifies what I meant. > Many of us have been very busy updating drafts for ietf deadline so it as been a hard time to respond. Hi Cullen, Welcome back :) That's understandable but next time might I suggest you reply immediately with: "You bring up good points but I am busy updating drafts for the ietf deadline. I'll reply as soon as I get this done..." At least then there is an acknowledgement that my points are being taken into consideration and an expectation that a response will arrive in the near future. The current process is very broken. We have a lot of discussions on the mailing list without any concrete action items. When a discussion thread goes unanswered, there is no follow-up. On the one hand, most organizations don't conduct such long discussions over a bug tracker but on the other hand a bug tracker provides the assurance that an issue will remain open until it is resolved to everyone's mutual satisfaction. Issues don't close silently as happens on mailing lists. We need to find a way to fix our process. Another thing I don't understand: As far as I know, the Working Group consists of http://www.w3.org/2000/09/dbwg/details?group=47318&public=1&order=org. That's around 78 people, yet none of them followed up on this. Where is the list of Working Group members that have an obligation to follow-up on these kind of posts? Meaning, who could I reasonably expect to reply? Thanks, Gili From stewe@stewe.org Fri Jul 19 09:03:44 2013 Return-Path: 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 B3B8321F85D1; Fri, 19 Jul 2013 09:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 iSmr16J+xtRR; Fri, 19 Jul 2013 09:03:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 754D421F85BB; Fri, 19 Jul 2013 09:03:29 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 19 Jul 2013 15:33:03 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.146]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.42]) with mapi id 15.00.0731.000; Fri, 19 Jul 2013 15:33:03 +0000 From: Stephan Wenger To: Justin Uberti , Bernard Aboba Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOhJVBdM05O/fEXUeQN07SatH6lQ== Date: Fri, 19 Jul 2013 15:33:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.202.147.60] x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(377424004)(13464003)(377454003)(2473001)(479174003)(16236675002)(76786001)(36756003)(81542001)(54316002)(83072001)(83322001)(74706001)(50986001)(53806001)(31966008)(76482001)(56776001)(4396001)(16406001)(51856001)(69226001)(47976001)(59766001)(8558605003)(47736001)(80022001)(15202345003)(74502001)(74876001)(49866001)(65816001)(81342001)(19580405001)(63696002)(74366001)(76796001)(54356001)(79102001)(74662001)(76176001)(77982001)(47446002)(56816003)(77096001)(19580385001)(46102001)(19580395003)(66066001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB191; H:CO1PR07MB191.namprd07.prod.outlook.com; CLIP:71.202.147.60; RD:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE0E9F569F89Bstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 16:03:44 -0000 --_000_CE0E9F569F89Bstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling=97as the encrypted in-band VPS would not be useful under the assu= mption that the middle box does not have the key to the media=97which is th= e motivation of the draft in the first place). I personally don't mind at = all the second mechanism, as I'm a big fan of out-of-band parameter set tra= nsmission and any middle box must be in the signaling path anyway to meanin= gfully manipulate RTP. I do not like the first option due to its variable,= and possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal= -layer-ext-00.txt Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for = VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CE0E9F569F89Bstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <733E8B5C549C77459614F7BC7CA923A3@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,
I also believe that 16 bits should be enough.  For H.264 and VP8 = that has already been demonstrated.  For H.265, some initial thoughts = below.  Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under developm= ent.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/= wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and t= here may well be cases where different pruning strategies may be advisable.=  For example, a layering structure could be constructed that expands = into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By lo= oking at the six bit field alone, a middle box will not be able to meaningf= ully remove NAL units belonging to one of the branches completely while pru= ning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the = dimension_id[][] (and associated control info) in the header extension, or = require the middle box to have access to the VPS and be able to interpret i= ts content.  The further could take considerably more than 16 bits and we would be talking about a variable le= ngth data structure.  The latter requires the middle box to have state= and a mechanism to intercept the VPS (through signaling=97as the encrypted= in-band VPS would not be useful under the assumption that the middle box does not have the key to the media=97wh= ich is the motivation of the draft in the first place).  I personally = don't mind at all the second mechanism, as I'm a big fan of out-of-band par= ameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP. &= nbsp;I do not like the first option due to its variable, and possibly subst= antial, overhead.

Stephan   


From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32 <= br> To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <= avtext@ietf.org>, "rtcweb@ie= tf.org" <rtcweb@ietf.org= >
Subject: Re: [rtcweb] Fwd: New Vers= ion Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in e= ach case there are fairly low limits on the number of supported layers (i.e= . 3 spatial layers for SVC), I think it should be possible to pack the temp= oral, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <= span dir=3D"ltr"> <bernard_= aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For e= xample, for H.264/SVC which can support temporal, spatial and quality scala= bility, you would need the quality_id and dependency_id in addition to the = temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline= .me
To: bernard_= aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with = any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline= .me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on = WebRTC services and have found that while developing services that forward = VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer infor= mation from the RTP header which requires us to decrypt the SRTP packets. T= his is undesirable both because the middle-box needs to have access to the = keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP he= ader extension that will allow us to use the VP8 temporal layer information= included in the header extension and therefore do forwarding without SRTP = decryption. Comments welcome.

Regards,=
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-0= 0.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com><= /td> 


A new version of I-D, dr=
aft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             ht=
tp://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-=
00.txt
Status:          http://datatr=
acker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ie=
tf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

--=20
Regards,
Adam


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


 --_000_CE0E9F569F89Bstewesteweorg_-- From salvatore.loreto@ericsson.com Fri Jul 19 09:12:17 2013 Return-Path: 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 65B1811E815C for ; Fri, 19 Jul 2013 09:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.021 X-Spam-Level: X-Spam-Status: No, score=-106.021 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 L7pVS2v7F2I6 for ; Fri, 19 Jul 2013 09:12:12 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 758C411E8151 for ; Fri, 19 Jul 2013 09:12:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-73-51e965584748 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 56.E1.06741.85569E15; Fri, 19 Jul 2013 18:12:08 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Fri, 19 Jul 2013 18:12:08 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 49A8B1102E8 for ; Fri, 19 Jul 2013 19:12:08 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 58392557B9 for ; Fri, 19 Jul 2013 19:12:04 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DA12B55590 for ; Fri, 19 Jul 2013 19:12:03 +0300 (EEST) Message-ID: <51E96556.4020905@ericsson.com> Date: Fri, 19 Jul 2013 18:12:06 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+JvrW5E6stAgxWvLC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqTTu1gKnrJULP1/ka2B8StzFyMHh4SAicTSuSxdjJxAppjE hXvr2boYuTiEBA4zSmxfMZsZwlnPKHHgbjdU5jKjxLq+iawQzhFGiQ/rd0KVnWWUOP+kjx1k GK+AtsTb7//BbBYBVYnj5xaDLWETMJN4/nALM4gtKpAs8f7KHWaIekGJkzOfgNWICIhKvH48 jRXkPmEBDYnmnf4gppBAgMTVmQogFZwCgRI9uyYwgtjMArYSF+ZcZ4Gw5SW2v53DDPGOmsTV c5vAbCEBLYnes51MExhFZiFZNgtJ+ywk7QsYmVcxsucmZuaklxtuYgQG8sEtv3V3MJ46J3KI UZqDRUmcd5PemUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjB7hKYlbvdY03q96GW4s0RD0 qG15m2QM1+c3z97UzjFsuJsVUdllpFKk0zyp9MjJvL57M5urusWz7xw7JndHK39+DGO3ttEE jn7GiQ/KrbbfL+Sb0uXYoBomz7nojtPtPrcbvKXqmVdTsk/MPC547Ff/xM6VEyfvOdNWJsGn YnfAw51LSGeiEktxRqKhFnNRcSIAGOsh4TICAAA= Subject: Re: [rtcweb] data channel reset X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 16:12:17 -0000 good catch! we will clarify and make it explicitly in the next version of the draft! thanks for the feedback /Sal On 7/19/13 12:39 AM, Martin Thomson wrote: > This statement, or something like it, is made in several places in the draft: > > "Channels are closed by an SCTP reset of the Stream." > > I assume that this uses the "Outgoing SSN Reset Request Parameter", > http://tools.ietf.org/html/rfc6525#section-4.1 > > Should it say that explicitly? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From adam@nostrum.com Fri Jul 19 09:37:57 2013 Return-Path: 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 86FA321E80DE for ; Fri, 19 Jul 2013 09:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 hjqLyQ3V-6Ux for ; Fri, 19 Jul 2013 09:37:57 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E379621E80DD for ; Fri, 19 Jul 2013 09:37:56 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JGbrrD069222 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 11:37:53 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E96B5B.2050302@nostrum.com> Date: Fri, 19 Jul 2013 11:37:47 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "" , "public-webrtc@w3.org" Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 16:37:57 -0000 On 7/19/13 10:03, Iñaki Baz Castillo wrote: > All these "smaller details" are in fact issues and problems we don't > need. Issues not needed at all in WebRTC, issues that WebRTC > developers and vendors should NOT care about. If those "smaller > details" do exist is due the mandate of SDP. And all the time the WG > (or WGs) will spent "fixing/defining" them is just wasted time, since > nothing useful is being done for WebRTC by "defining" those "minor > details". > I think this is a hopelessly naïve interpretation of the facts on the ground. Simply discarding SDP doesn't magically make the underlying issues go away. We would still need to settle a vast number of issues around things like simulcast, FEC, codec parameters, indication of supported codecs, correlation of RTP streams with MediaStreamTracks, attempts by both parties to operate on the same stream simultaneously [1], etc. Basically, with very rare exception, the same set of problems that we need to solve if we *don't* throw SDP out the window. I understand the temptation to think that starting over makes all the problems go away. There's a mental trap in thinking that all you really need is to announce ports and codecs and get on with it. But then this person over here really needs simulcast. And that person over there insists that RTCP NACK feedback is critical for his application. And then I need to be able to tell you that your 1280x720 video stream is going to overwhelm my limited ability to decode and that you really need to turn it down to QCIF. And, before you know it, you've reinvented something approximately as complex as SDP that everyone is just going to shove into a JSON blob and send across the wire. As an added bonus, by deciding that legacy interop is of no value, you've limited the utility of the overall system by setting Metcalfe's law on fire and throwing it over the railing of the third-floor balcony. Your pain point isn't SDP syntax. Yeah, it's ugly, but it's not hard. Your pain point isn't offer/answer. Two unilaterally declared sessions that are simply blasted out onto the wire only satisfies the simplest of use cases; you need a negotiation, and any attempt to define how that negotiation looks is going to arrive at something with enough rules that it is substantially as complicated as offer/answer. No, your pain point here is that non-master-slave networked communications are not easy to get right, and it is the height of hubris to think that you inherently know better than everyone else who has worked in this space before you. Consider that TCP has far fewer moving parts than even a simple one-stream-audio-only call setup and took 85 pages to specify. I understand comment 22 at its core [2], but it has a corollary: any system that replaces SDP O/A will end up being similar in complexity once all interested parties' use cases have been factored in. /a ____ [1] What we call "glare" in telecom and SIP, but a phenomenon that arises whenever you have connections made between peers without a master/slave arrangement; see RFC 793, page 32, for example. [2] For the uninitiated, "comment 22" was a shorthand developed at last year's TPAC for the sentiment "SDP offer/answer is hard". From martin.thomson@gmail.com Fri Jul 19 09:54:22 2013 Return-Path: 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 B40C621F9A26 for ; Fri, 19 Jul 2013 09:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, 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 2gF1WSm0LptH for ; Fri, 19 Jul 2013 09:54:21 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id C081521E80C7 for ; Fri, 19 Jul 2013 09:54:18 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so30485wib.0 for ; Fri, 19 Jul 2013 09:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x84iXLIgKGdTaNOF1RzCxhMlI9O1MryPPLSEwKpHrtM=; b=e8mjCrOqFVW6BqGCC/CBxPlKPxrRycvtLHbKQv+ELHlw9fuXZgNcNXzQ1mUkl0pab4 bSyThVffxapP0lYrf/OTUrAr010+CB8GViV8AIPRhtAGgPDI8PkwLNF8j88ZyvwCgyJ5 NR48WF2kr8dB+UKnfQr2M/C6jdE20rwyCkNLw1EOMSxhlPNtWAgBP1XMOqVMCLVmdck0 iSBHjdpeayjLAGdbEiYdEw7/taiO8TL5rSeOPvPHvaDr+vAzkqPCAKq1W2yZyMBXRImM +VNeiD/2VJH0XkUfZVffTnCY8neRSktdSb3HdPtv4+Yh2gzxiVkgD7pMbDclPm1lSVrD b8SQ== MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr12011545wic.65.1374252852544; Fri, 19 Jul 2013 09:54:12 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 19 Jul 2013 09:54:12 -0700 (PDT) In-Reply-To: <51E96B5B.2050302@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> Date: Fri, 19 Jul 2013 09:54:12 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 16:54:23 -0000 On 19 July 2013 09:37, Adam Roach wrote: > [2] For the uninitiated, "comment 22" was a shorthand developed at last > year's TPAC for the sentiment "SDP offer/answer is hard". No quite, it's shorthand for "there is a proposal that has been submitted in which the problem in question does not need to be solved", with one of two options: "either the problem has been solved", or "the problem simply does not need to be solved (by us, with a standard)". I reject your thesis for one simple reason: scope. As it turns out, "does not need to be solved" doesn't go to 100%. Some problems are deferred to applications. Intentionally. Because a) they are better at that than we are, clearly, and b) they don't necessarily want our crappy solutions. How long have we talked about BUNDLE? How long do you think that it would take someone with a functioning RTP library to build something that multiplexes and demultiplexes RTP streams? Negotiation is a hole. A vast, soul-sucking, waste of time. From ted.ietf@gmail.com Fri Jul 19 10:07:20 2013 Return-Path: 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 ACB1621E80D6 for ; Fri, 19 Jul 2013 10:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, 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 kjV7JINNVkgL for ; Fri, 19 Jul 2013 10:07:20 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 104FF21E80E2 for ; Fri, 19 Jul 2013 10:07:13 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so9932231ieb.30 for ; Fri, 19 Jul 2013 10:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NwwebRZS0kDjsKGXB9DbTWwkEh5g+mnACU2Qxg88hGQ=; b=ZfsfLeBKdnXiMMKC9FyqtVgkCHdv6zjBr1ApKxbAy/cAhNXeetc79QBTDRc0PF3YkE 7ei+cxJ+OEkMUhQMdCkYfLw6+fXr4gN/R70kZQ0zoEYC/m2sO6x2seciywGJqwLITQ44 zosIbxLc9GdflFRxMiwSWcdGAhaDGp8oLtrsoVCjtE2X2m20ivPMZG2yRvFPo3eiznnx JPcTpIwj1CtdJM0LBKOXhQ6Hb+jXxgs55CwubIF47dbGYmKhmjCs6Ju6TXPqCNcsPLyI 9dPr4XmiqCnNP+2uzyj0DGJGjL8E+uSfX4aBviyMKQlAYuuYvTFAzR9ciCH+pEFCROj6 dnig== MIME-Version: 1.0 X-Received: by 10.43.67.73 with SMTP id xt9mr11327726icb.99.1374253632667; Fri, 19 Jul 2013 10:07:12 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Fri, 19 Jul 2013 10:07:12 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> Date: Fri, 19 Jul 2013 10:07:12 -0700 Message-ID: From: Ted Hardie To: Martin Thomson Content-Type: multipart/alternative; boundary=089e015370969b50ad04e1e05bfc Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:07:20 -0000 --089e015370969b50ad04e1e05bfc Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 9:54 AM, Martin Thomson wrote: > > Negotiation is a hole. A vast, soul-sucking, waste of time. > > Even if you have the same javascript application downloaded, you will have disparate capabilities in the environments into which it is downloaded (browser/os/codecs/media sources/available network capacity). Getting set intersection and preference order for those capabilities is something that applications actually want. You may be able to move the pain of that around, but it isn't a waste of time. My personal opinion, with no IETF hats or company swag, Ted --089e015370969b50ad04e1e05bfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jul 19, 2013 at 9:54 AM, Martin Thomson <martin.thomson@gma= il.com> wrote:

Negotiation is a hole. =A0A vast, soul-sucking, waste of time.


Even if you have the same javascript application dow= nloaded, you will have disparate capabilities in the environments into whic= h it is downloaded (browser/os/codecs/media sources/available network capac= ity).=A0 Getting set intersection and preference order for those capabiliti= es is something that applications actually want.=A0 You may be able to move= the pain of that around, but it isn't a waste of time.

My personal opinion, with no IETF hats or company swag,

Ted
--089e015370969b50ad04e1e05bfc-- From adam@nostrum.com Fri Jul 19 10:09:47 2013 Return-Path: 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 A407E11E8163 for ; Fri, 19 Jul 2013 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 9cNm77OkVzIx for ; Fri, 19 Jul 2013 10:09:47 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D208611E80E1 for ; Fri, 19 Jul 2013 10:09:46 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JH9bdJ072694 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 12:09:38 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E972CC.1020104@nostrum.com> Date: Fri, 19 Jul 2013 12:09:32 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Martin Thomson References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:09:48 -0000 On 7/19/13 11:54, Martin Thomson wrote: > As it turns out, "does not need to be solved" doesn't go to 100%. > Some problems are deferred to applications. Intentionally. Because > a) they are better at that than we are, clearly, and b) they don't > necessarily want our crappy solutions. > > How long have we talked about BUNDLE? How long do you think that it > would take someone with a functioning RTP library to build something > that multiplexes and demultiplexes RTP streams? Are you proposing that Firefox come up with its own multiplexing mechanism for RTP; Chrome its own; Opera, yet a third; IE, a fourth; and Safari, a fifth? And then we just kind of pray that five proprietary solutions developed in a vacuum miraculously work together? I mean, yeah, if we can rely on miracle interop for independently-developed proprietary solutions, I guess that works. Or are you envisioning a WebRTC API that requires javascript applications to supply their own RTP stacks? /a From pthatcher@google.com Fri Jul 19 10:18:53 2013 Return-Path: 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 12B6021F9CE7 for ; Fri, 19 Jul 2013 10:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.239, 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 YNHL+o-GCewx for ; Fri, 19 Jul 2013 10:18:52 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2781B21F9C72 for ; Fri, 19 Jul 2013 10:18:50 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md12so4645768pbc.16 for ; Fri, 19 Jul 2013 10:18:49 -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=2hQ9Obl7mM61INi7YiSdbyfLFr6FHf4tyZAibNi3lqM=; b=Nv4YlI02CeUc+OhOhzKBdK9mEDtyvVAqjnBfc9QyUHDtAxpnyjNK/ceBn6iKzzU93s ynop6LDGsz72VQYtc6MbdkaMwVpjbkpxR4kUjeIJLuHWZnzByLa2CsMNWkVEGBjk6TjX ckN9KAUp6uEsjteErZfM7JC9rEPV2nikp8F2iLNxow2YkMwwsr+zuyA6z3rk/vG730Fi fwQFUEsEcujs6MUz05YhQ4M1uJNjOzI9cjqoF4guNWvQyWJFWVD2MTizZVwxLlCJ95+t LF5S454Vvy/yTB64uaeasmAteYzRrpn4x0pswSaxP035eKpg8gCgwhZmOfv3r/hB3n57 zWPQ== 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=2hQ9Obl7mM61INi7YiSdbyfLFr6FHf4tyZAibNi3lqM=; b=S2yUIrbf2/j0KwRjAKj0pyTAy7bPgJ1dvX1ZVdPVPDETCFlQUdNy0DqgOE2JqBcMEV 5HUdDitu0bo+dTOeQ6rWOUw3KtuP8rnG5GPynsXtZdpf/vo9LxFWVVtW9rIJi5rulsp8 SC/xkBtpsYUOBUYMyfdxDPkCaEPpia/vFiCtVu9trAUrF0bk7OtZjLt+O8N45iv6++7I dBRqHgQhqx1RGgySDg626XAeS6Ct7+PKWlbzmavpnp/Pd2vLldCRyjggge/Ip4JA+7Gw C5/nPjf4edudwjNS4BjUzUfK3z/RirHESQSlsw4xYhqj7Ro7u6mEArvoGgRzpj/2TRT0 0WHQ== X-Received: by 10.66.217.195 with SMTP id pa3mr19411711pac.120.1374254329682; Fri, 19 Jul 2013 10:18:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 10:18:09 -0700 (PDT) In-Reply-To: <51E96B5B.2050302@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 10:18:09 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=047d7b5d438c26fb5104e1e085c4 X-Gm-Message-State: ALoCoQkqZX4ur6dihFrVfuHZ6Qz6PiHsbdZ9JhK2XJGcJU5PNaGsi7HpTmqfV6IObNQTUcUEA1dC29TsvdDKTm8eeaJlGYsqUry5amBo0JLK9F+IxFfmHKbLs8nc3uK6JdmGx2zxvQqtp48mwoeWEINSRZHwajGwGI5Ly3Bctfnow1cHDFFN+Om2IZHmsVyk8Fe3Fjsjj+bs Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:18:53 -0000 --047d7b5d438c26fb5104e1e085c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 19, 2013 at 9:37 AM, Adam Roach wrote: > On 7/19/13 10:03, I=C3=B1aki Baz Castillo wrote: > >> All these "smaller details" are in fact issues and problems we don't >> need. Issues not needed at all in WebRTC, issues that WebRTC >> developers and vendors should NOT care about. If those "smaller >> details" do exist is due the mandate of SDP. And all the time the WG >> (or WGs) will spent "fixing/defining" them is just wasted time, since >> nothing useful is being done for WebRTC by "defining" those "minor >> details". >> >> > I think this is a hopelessly na=C3=AFve interpretation of the facts on th= e > ground. Simply discarding SDP doesn't magically make the underlying issue= s > go away. We would still need to settle a vast number of issues around > things like simulcast, FEC, codec parameters, indication of supported > codecs, correlation of RTP streams with MediaStreamTracks, attempts by bo= th > parties to operate on the same stream simultaneously [1], etc. Basically, > with very rare exception, the same set of problems that we need to solve = if > we *don't* throw SDP out the window. > It's interesting that most or your list of things that needed to be solved without SDP (simulcast, FEC, correlation of RTP streams with MediaStreamTracks, glare) still haven't been solved for WebRTC even with SDP, despite many months (years?) of effort. I don't think anyone is saying "without SDP, there would be issues". I think they're saying "without SDP, the issues are much easier/faster to solve, and the API would be much more usable and implementable". And I don't think that's a naive opinion. > > I understand the temptation to think that starting over makes all the > problems go away. There's a mental trap in thinking that all you really > need is to announce ports and codecs and get on with it. But then this > person over here really needs simulcast. And that person over there insis= ts > that RTCP NACK feedback is critical for his application. And then I need = to > be able to tell you that your 1280x720 video stream is going to overwhelm > my limited ability to decode and that you really need to turn it down to > QCIF. And, before you know it, you've reinvented something approximately > as complex as SDP I think you are conflating signalling with API surface. If we focus on making a good API rather than on signalling, we can make something much more simple and leave signalling up to the application. > that everyone is just going to shove into a JSON blob and send across the > wire. As an added bonus, by deciding that legacy interop is of no value, > you've limited the utility of the overall system by setting Metcalfe's la= w > on fire and throwing it over the railing of the third-floor balcony. Again, you are conflating API surface and signalling. An API that doesn't have SDP in it doesn't preclude web apps from using SDP for signalling. There's no loss here for those app that choose to use SDP. There is only gain for web developers chooses not to use SDP for the signalling in their web application. And if they choose not to use SDP and use JSON instead, why are you so opposed? There is a world outside of legacy interop, you know. > > > Your pain point isn't SDP syntax. Yeah, it's ugly, but it's not hard. You= r > pain point isn't offer/answer. Two unilaterally declared sessions that ar= e > simply blasted out onto the wire only satisfies the simplest of use cases= ; > you need a negotiation, and any attempt to define how that negotiation > looks is going to arrive at something with enough rules that it is > substantially as complicated as offer/answer. > You are underestimating how painful it is to deal with the current API, both because you are very familiar with it (with many years of experience) and because the use cases you care about are the ones the API was defined for (legacy interop). But as soon as you ask someone who is not familiar with SDP (a lot of web devleopers), or someone who is doing more advanced or different things than what you have thought of, they will give you a different answer. They feel pain, and it is because of the poor API surface. > > No, your pain point here is that non-master-slave networked communication= s > are not easy to get right, and it is the height of hubris to think that y= ou > inherently know better than everyone else who has worked in this space > before you. Consider that TCP has far fewer moving parts than even a simp= le > one-stream-audio-only call setup and took 85 pages to specify. > Please try to consider what you sound like to a web developer who is trying to use WebRTC and finding SDP to be difficult API surface. Maybe I'm wrong, but I'm guessing what you're saying will sound like. "my use case (legacy interop) is the most important and my solution (SDP) is the best solution for everyone and I know better because I've been working on it for longer". Hubris? > > I understand comment 22 at its core [2], but it has a corollary: any > system that replaces SDP O/A will end up being similar in complexity once > all interested parties' use cases have been factored in. > There is a vast difference that you are not taking into account. The SDP O/A, if in JS, is a complexity cost only paid by those web applications that need it. But if baked into the API, every app must pay the cost of the complexity. In general, this emails seems to be arguing that SDP is the optimal API surface for expressing all these complex things, and yet in other occasions, I've heard you admit it's a terrible API surface. So does that mean the optimal API surface is terrible? I don't think so. It will be work, but I think the work will be worth it in the end. That said, the chairs have asked us to delay discussing a better API, so we'll have to wait before we can discuss details of how an API could be done without SDP. > > /a > > ____ > [1] What we call "glare" in telecom and SIP, but a phenomenon that arises > whenever you have connections made between peers without a master/slave > arrangement; see RFC 793, page 32, for example. > > [2] For the uninitiated, "comment 22" was a shorthand developed at last > year's TPAC for the sentiment "SDP offer/answer is hard". > > --047d7b5d438c26fb5104e1e085c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 9:37 AM, Adam Roach <<= a href=3D"mailto:adam@nostrum.com" target=3D"_blank">adam@nostrum.com&g= t; wrote:
On 7/19/13 10:03, I=C3=B1aki Baz Castillo wrote:
All these "smaller details" are in fact issues and problems we do= n't
need. Issues not needed at all in WebRTC, issues that WebRTC
developers and vendors should NOT care about. If those "smaller
details" do exist is due the mandate of SDP. And all the time the WG (or WGs) will spent "fixing/defining" them is just wasted time, s= ince
nothing useful is being done for WebRTC by "defining" those "= ;minor
details".


I think this is a hopelessly na=C3=AFve interpretation of the facts on the = ground. Simply discarding SDP doesn't magically make the underlying iss= ues go away. We would still need to settle a vast number of issues around t= hings like simulcast, FEC, codec parameters, indication of supported codecs= , correlation of RTP streams with MediaStreamTracks, attempts by both parti= es to operate on the same stream simultaneously [1], etc. Basically, with v= ery rare exception, the same set of problems that we need to solve if we *d= on't* throw SDP out the window.

It's interesting that most or your lis= t of things that needed to be solved without SDP (simulcast, FEC, correlati= on of RTP streams with MediaStreamTracks, glare) still haven't been sol= ved for WebRTC even with SDP, despite many months (years?) of effort. =C2= =A0

I don't think anyone is saying "without SDP, t= here would be issues". =C2=A0I think they're saying "without = SDP, the issues are much easier/faster to solve, and the API would be much = more usable and implementable". =C2=A0 And I don't think that'= s a naive opinion.


=C2=A0

I understand the temptation to think that starting over makes all the probl= ems go away. There's a mental trap in thinking that all you really need= is to announce ports and codecs and get on with it. But then this person o= ver here really needs simulcast. And that person over there insists that RT= CP NACK feedback is critical for his application. And then I need to be abl= e to tell you that your 1280x720 video stream is going to overwhelm my limi= ted ability to decode and that you really need to turn it down to QCIF. =C2= =A0And, before you know it, you've reinvented something approximately a= s complex as SDP

I think you are conflating signalling with API surface.= =C2=A0If we focus on making a good API rather than on signalling, we can m= ake something much more simple and leave signalling up to the application.<= /div>
=C2=A0
that everyone is just going to shove into= a JSON blob and send across the wire. =C2=A0As an added bonus, by deciding= that legacy interop is of no value, you've limited the utility of the = overall system by setting Metcalfe's law on fire and throwing it over t= he railing of the third-floor balcony.

Again, you are conflating API surface and signalling. = =C2=A0An API that doesn't have SDP in it doesn't preclude web apps = from using SDP for signalling. =C2=A0There's no loss here for those app= that choose to use SDP. =C2=A0There is only gain for web developers choose= s not to use SDP for the signalling in their web application. =C2=A0And if = they choose not to use SDP and use JSON instead, why are you so opposed? = =C2=A0There is a world outside of legacy interop, you know. =C2=A0


=C2=A0



=C2=A0
Your pain point isn't SDP syntax. Yeah, it's ugly, but it's not= hard. Your pain point isn't offer/answer. Two unilaterally declared se= ssions that are simply blasted out onto the wire only satisfies the simples= t of use cases; you need a negotiation, and any attempt to define how that = negotiation looks is going to arrive at something with enough rules that it= is substantially as complicated as offer/answer.

You are underestimating how painful it is = to deal with the current API, both because you are very familiar with it (w= ith many years of experience) and because the use cases you care about are = the ones the API was defined for (legacy interop). =C2=A0But as soon as you= ask someone who is not familiar with SDP (a lot of web devleopers), or som= eone who is doing more advanced or different things than what you have thou= ght of, they will give you a different answer. =C2=A0 They feel pain, and i= t is because of the poor API surface.

=C2=A0

No, your pain point here is that non-master-slave networked communications = are not easy to get right, and it is the height of hubris to think that you= inherently know better than everyone else who has worked in this space bef= ore you. Consider that TCP has far fewer moving parts than even a simple on= e-stream-audio-only call setup and took 85 pages to specify.

Please try to consider what you sound like= to a web developer who is trying to use WebRTC and finding SDP to be diffi= cult API surface. =C2=A0Maybe I'm wrong, but I'm guessing what you&= #39;re saying will sound like. =C2=A0"my use case (legacy interop) is = the most important and my solution (SDP) is the best solution for everyone = and I know better because I've been working on it for longer". =C2= =A0Hubris? =C2=A0
=C2=A0

I understand comment 22 at its core [2], but it has a corollary: any system= that replaces SDP O/A will end up being similar in complexity once all int= erested parties' use cases have been factored in.

There is a vast difference that you are not taking into= account. =C2=A0The SDP O/A, if in JS, is a complexity cost only paid by th= ose web applications that need it. =C2=A0But if baked into the API, every a= pp must pay the cost of the complexity. =C2=A0

In general, this emails seems to be arguing that =C2=A0= SDP is the optimal API surface for expressing all these complex things, and= =C2=A0yet in other occasions, I've heard you admit it's a terrible= API surface. =C2=A0So does that mean the optimal API surface is terrible? = =C2=A0I don't think so. =C2=A0It will be work, but I think the work wil= l be worth it in the end. =C2=A0

That said, the chairs have asked us to delay discussing= a better API, so we'll have to wait before we can discuss details of h= ow an API could be done without SDP.=C2=A0
=C2=A0

/a

____
[1] What we call "glare" in telecom and SIP, but a phenomenon tha= t arises whenever you have connections made between peers without a master/= slave arrangement; see RFC 793, page 32, for example.

[2] For the uninitiated, "comment 22" was a shorthand developed a= t last year's TPAC for the sentiment "SDP offer/answer is hard&quo= t;.


--047d7b5d438c26fb5104e1e085c4-- From martin.thomson@gmail.com Fri Jul 19 10:20:18 2013 Return-Path: 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 9C05611E80FD for ; Fri, 19 Jul 2013 10:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, 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 a65+wauAYZkO for ; Fri, 19 Jul 2013 10:20:16 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6647821F9DD0 for ; Fri, 19 Jul 2013 10:20:16 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p59so356248wes.11 for ; Fri, 19 Jul 2013 10:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oE5Datqa5eoOdO7n1vhmz2A6XNSb5LwoCpV6cApQc40=; b=YBrra+8PJ3pc3RCs1ulR/b5Qmexuj9zO03ABY4M4iaNLMx/WdTnEbmkNiwk38+XUPL mjGaHPNN6iQbk3/4dJEHvz+MAtJQwAt5qz2+pi6Of3lU57A3nRSgX8bXmKSgCs1GNWiS fjck7vqJc8KoE0cScflsEdPAVoD5OQhS60FfxiD+Zk0gMXKCgpV18wcI3c23swXTA5Y1 UHqwylGP2yxkVKYszH/XTntw3rx3AwYGVy6CFxLowodpmd0OSKvz6zahaLJbnLFQ0FmH pPanQ0H7mMD4jo2ZHfimdBIISxbSICpGjHRa+Zu45QZ6ws1tlWfSPURvLi9QtPsBHW3L i8yg== MIME-Version: 1.0 X-Received: by 10.180.9.212 with SMTP id c20mr23256584wib.65.1374254415553; Fri, 19 Jul 2013 10:20:15 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 19 Jul 2013 10:20:15 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> Date: Fri, 19 Jul 2013 10:20:15 -0700 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:20:18 -0000 On 19 July 2013 10:07, Ted Hardie wrote: > Even if you have the same javascript application downloaded, you will have > disparate capabilities in the environments into which it is downloaded > (browser/os/codecs/media sources/available network capacity). Getting set > intersection and preference order for those capabilities is something that > applications actually want. You may be able to move the pain of that > around, but it isn't a waste of time. There's a vast difference between "it needs to be done" and "we need to define a standard for it". I have nothing against providing tools that make it easier, but it's a real leap of logic to conclude that the one and only mechanism for interaction *requires* negotiation and that SDP O/A is *the* negotiation method. From martin.thomson@gmail.com Fri Jul 19 10:23:06 2013 Return-Path: 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 B3AF121E8100 for ; Fri, 19 Jul 2013 10:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, 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 5j-d0F5IO4Jz for ; Fri, 19 Jul 2013 10:23:06 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id F134321E8050 for ; Fri, 19 Jul 2013 10:23:05 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so4300935wes.9 for ; Fri, 19 Jul 2013 10:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nqoXoOESqtjxOuXFaEMEMrJSWyScuhoh3XWFddYBxgk=; b=Zo92RmqC5wyY03XBYNcg5K9JyKO+j/zE3KFqUHL2HzaX1du1WZGrcXpYX32JKJVAGV jb+cKHyMWQ5OsUQ4oryUvUUnM2Juu8FZAn5N5xE7OlKj35076gW7HFvds84hGhxhJUYB +vUv6MbzoDzb1fH3nhMAo0jK4yRUyRxV3kHpG+ASWkgqhAo+SpZPuUm6Vw+xt9aap7Z+ HzJyyrEqczLux/7HN/IbpTBLjwwreyaxwSNZ6XXxMJXpUn9cce+9yiySy6A5UmaCVWVE I8VAW81rV7IiqpjAzJsaTURjj9d08nnGVFZaNjwpsBodaADcaPN5H/fhA8pTtBylZK4K mbnw== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr12861004wjx.84.1374254585140; Fri, 19 Jul 2013 10:23:05 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 19 Jul 2013 10:23:05 -0700 (PDT) In-Reply-To: <51E972CC.1020104@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E972CC.1020104@nostrum.com> Date: Fri, 19 Jul 2013 10:23:05 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:23:06 -0000 On 19 July 2013 10:09, Adam Roach wrote: > Are you proposing that Firefox come up with its own multiplexing mechanism > for RTP; Chrome its own; Opera, yet a third; IE, a fourth; and Safari, a > fifth? And then we just kind of pray that five proprietary solutions > developed in a vacuum miraculously work together? I mean, yeah, if we can > rely on miracle interop for independently-developed proprietary solutions, I > guess that works. I'm saying nothing of the sort. We definitely need to define what multiplexing looks like when it happens, but there's a vast gulf between that and defining how to negotiate it. Discussions on RTP shims or SSRC mux did consume some time, but I believe them to be done. For quite a while now. The negotiation part looks like it's nearing completion, but only after a fairly significant amount of wrangling and pain. From pthatcher@google.com Fri Jul 19 10:24:40 2013 Return-Path: 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 CE7AB11E815E for ; Fri, 19 Jul 2013 10:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 EdFy7g58ZKfj for ; Fri, 19 Jul 2013 10:24:40 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 450DA11E8147 for ; Fri, 19 Jul 2013 10:24:40 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj3so4696596pad.14 for ; Fri, 19 Jul 2013 10:24:39 -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=YqABa7ml8eLslU8E4mLoxYOPgpNyxilrvwbs2v2t1y4=; b=fFjzmB3k+KkFeRMa9mfTSlxUJ07h+5avySIEXiym08wIIEdgA9kY0jvc4f2Z2U2WHd glTaChsB88tTElJ+SjHI0ivHM20LTMhJJ0FNLnjcJPZWkSO2JlOnrMDE5A2MA7nZ4lRL PQeCvUNlcLTOSF88aCP3HuNifSwMubzuZBQ0SW9yu/HAlFv/7om7RJi++udKCRR+AXMN 3JrGanCuvTcYu8Au6SajQ2CgUt/p68Uztt24pn7JbtaWHECt5yK6cpyIM7CPRG7CFnES 3lCntmviKu31dsvmO5JbkDF6UF9SIZmHmUD8KPVn0vbSzEkNZfPOe3LALyYARXB3vTgf NoSQ== 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=YqABa7ml8eLslU8E4mLoxYOPgpNyxilrvwbs2v2t1y4=; b=C7lZ8FOpQGbPlcCvb5znFYo+SR4jlwtGBfAoQbqoNM4DPmizFVTBw8X/qVe7nnNMQO hXiZMEkQZdCsXi9iRinvWTuqeitDUuPtgTGZyCMWQEzO2kkmCmaeY4u5FEi3JnVC1eGn CTmP3jsYGkiLXhG2PqWyLuFBIzwnR20le2KD5WB+vyOpLJ3VVqJL+yVrOIR+aEeS5ODd dUjfSG5XDsVAxque508ie1tbUPGSr+zTkIdsOdiFzEG9yl73Leh0De48wpPHx+zj7lpP vIqCbdHcHzBYBXQB7Y2JQTEQX8dRZBbt1dYiGYB2qPm7bftvdfhjO3nBtNe239wbaFwb zRSQ== X-Received: by 10.66.228.72 with SMTP id sg8mr19329377pac.45.1374254679835; Fri, 19 Jul 2013 10:24:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 10:23:59 -0700 (PDT) In-Reply-To: <51E972CC.1020104@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E972CC.1020104@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 10:23:59 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=047d7b111cff05e44404e1e09a8e X-Gm-Message-State: ALoCoQnzYbxRGNba7IKnScnSKQtW/C6n+SeAsgFYyXsnpLt6YW78B8s2PPYzQ+dgPEcdJvzEzVmBxHWS7AGl7WTrJ3+zIFOdaSIdCEfEMSyiALtsMIZWRPjfnOOqgExht+AcspsCEqV+ujLtjQhFU0Zz85qYbWZySAuGJxtycZHDFXbJp91GRPfOjCsS80eyZ21wiogmR79Y Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:24:40 -0000 --047d7b111cff05e44404e1e09a8e Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 10:09 AM, Adam Roach wrote: > On 7/19/13 11:54, Martin Thomson wrote: > >> As it turns out, "does not need to be solved" doesn't go to 100%. >> Some problems are deferred to applications. Intentionally. Because >> a) they are better at that than we are, clearly, and b) they don't >> necessarily want our crappy solutions. >> >> How long have we talked about BUNDLE? How long do you think that it >> would take someone with a functioning RTP library to build something >> that multiplexes and demultiplexes RTP streams? >> > > Are you proposing that Firefox come up with its own multiplexing mechanism > for RTP; Chrome its own; Opera, yet a third; IE, a fourth; and Safari, a > fifth? And then we just kind of pray that five proprietary solutions > developed in a vacuum miraculously work together? I mean, yeah, if we can > rely on miracle interop for independently-developed proprietary solutions, > I guess that works. > > Again, you are conflating signalling and API surface. We could define a simple API that leaves the control up the application, and different applications can signal different multiplexing techniques in different ways. > Or are you envisioning a WebRTC API that requires javascript applications > to supply their own RTP stacks? SDP != RTP. It is possible to have an RTP stack without an SDP stack. You realize this, right? > > > /a > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --047d7b111cff05e44404e1e09a8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 10:09 AM, Adam Roach <= adam@nostrum.com&= gt; wrote:
On 7/19/13 11:54, Martin T= homson wrote:
As it turns out, "does not need to be solved" doesn't go to 1= 00%.
Some problems are deferred to applications. =C2=A0Intentionally. =C2=A0Beca= use
a) they are better at that than we are, clearly, and b) they don't
necessarily want our crappy solutions.

How long have we talked about BUNDLE? =C2=A0How long do you think that it would take someone with a functioning RTP library to build something
that multiplexes and demultiplexes RTP streams?

Are you proposing that Firefox come up with its own multiplexing mechanism = for RTP; Chrome its own; Opera, yet a third; IE, a fourth; and Safari, a fi= fth? =C2=A0And then we just kind of pray that five proprietary solutions de= veloped in a vacuum miraculously work together? I mean, yeah, if we can rel= y on miracle interop for independently-developed proprietary solutions, I g= uess that works.


Again, you are conflating signalling a= nd API surface. =C2=A0We could define a simple API that leaves the control = up the application, and different applications can signal different multipl= exing techniques in different ways.=C2=A0
=C2=A0
Or are you envisioning a WebRTC API that requires javascript applications t= o supply their own RTP stacks?

SDP !=3D RTP= . =C2=A0 It is possible to have an RTP stack without an SDP stack. =C2=A0Yo= u realize this, right?

=C2=A0


/a

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

--047d7b111cff05e44404e1e09a8e-- From adam@nostrum.com Fri Jul 19 10:25:22 2013 Return-Path: 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 4C29911E8174 for ; Fri, 19 Jul 2013 10:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Och8k-CRL2+c for ; Fri, 19 Jul 2013 10:25:21 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 09F2F11E8147 for ; Fri, 19 Jul 2013 10:25:20 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JHPG1T074495 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 12:25:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E97677.1020902@nostrum.com> Date: Fri, 19 Jul 2013 12:25:11 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Hardie References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090605080100040702020800" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:25:22 -0000 This is a multi-part message in MIME format. --------------090605080100040702020800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/19/13 12:07, Ted Hardie wrote: > On Fri, Jul 19, 2013 at 9:54 AM, Martin Thomson > > wrote: > > > Negotiation is a hole. A vast, soul-sucking, waste of time. > > > Even if you have the same javascript application downloaded, you will > have disparate capabilities in the environments into which it is > downloaded (browser/os/codecs/media sources/available network > capacity). Getting set intersection and preference order for those > capabilities is something that applications actually want. You may be > able to move the pain of that around, but it isn't a waste of time. I can't +1 this hard enough. I certainly don't want every javascript application that makes use of the WebRTC API to independently discover that mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to unusable if you try to send it more than 320x200 video, and then try to solve that problem. Again and again, for every permutation of phone and operating system version. Yeah, someone has to do this kind of characterization, and some of it can be done real-time if you're interacting directly with the operating system. So... maybe we could add yet another API to WebRTC to allow applications to build this functionality themselves rather than counting on them characterizing the systems they care about and blowing up on the ones they don't. But, honestly, any course of action that relegates this to the applications seems to have the dual properties of forcing it to be implemented hundreds of thousands of times while making the actual user experience worse. /a --------------090605080100040702020800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/19/13 12:07, Ted Hardie wrote:
On Fri, 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.


Even if you have the same javascript application downloaded, you will have disparate capabilities in the environments into which it is downloaded (browser/os/codecs/media sources/available network capacity).  Getting set intersection and preference order for those capabilities is something that applications actually want.  You may be able to move the pain of that around, but it isn't a waste of time.

I can't +1 this hard enough. I certainly don't want every javascript application that makes use of the WebRTC API to independently discover that mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to unusable if you try to send it more than 320x200 video, and then try to solve that problem.

Again and again, for every permutation of phone and operating system version.

Yeah, someone has to do this kind of characterization, and some of it can be done real-time if you're interacting directly with the operating system. So... maybe we could add yet another API to WebRTC to allow applications to build this functionality themselves rather than counting on them characterizing the systems they care about and blowing up on the ones they don't.

But, honestly, any course of action that relegates this to the applications seems to have the dual properties of forcing it to be implemented hundreds of thousands of times while making the actual user experience worse.

/a
--------------090605080100040702020800-- From pthatcher@google.com Fri Jul 19 10:28:21 2013 Return-Path: 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 E295711E818F for ; Fri, 19 Jul 2013 10:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.251, 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 nds0xt+pFix3 for ; Fri, 19 Jul 2013 10:28:21 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 073A511E8194 for ; Fri, 19 Jul 2013 10:28:18 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so4687891pbb.14 for ; Fri, 19 Jul 2013 10:27:56 -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=cpO8YJMHy80YhX/6i+9Ebw+9o2SxwrlnD30KSbsXMQU=; b=XtzK1Or6/SlFYZyrQO5iH8CtK1zDpvYKL5yx25cJw+Byut+Lml1MzuQZY+kVchvcxV Av87RBaI7yzxiBghSgyZSJIdl7y+rLzIUrsF0rLNG6PY1MVjAkFBYIdwTIYXmZXYuqLH 9lMpfR+bFyjxw1/TNPzyMGnRHDE+s5edB+o1NHUi+DNnhSvSPbNrKgGj05OUcfvgXajb i+TjSh3YFbEhLvJN3/l8FexAUo2V0/kECwTc6RYHKpfxt0eBDFPGYZba+LA5fJaBwbdj LeCvLLtZlNnPuh2QgP/j41WP2X7VM9G5CuTh+qnerPcLRNxdNl7KVDhT00+PxoQS7Se8 2cgw== 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=cpO8YJMHy80YhX/6i+9Ebw+9o2SxwrlnD30KSbsXMQU=; b=Lv41k6v5gWm5LR1osEgX+6JzrHe0iyJ8Q5Qw9EFJCGMcMpUzjKg1UvmJx9wgWe383g qwPOhkkfyVILTkiX2DuDS2hvM8uxUYPTP5TR+urQYIAeRMRuwyoHTbbp11OTHTj9MvcJ 0+Mtio8uNz361wb2xcfbZEZqxTkbbh93PvQ2Vo5mP+urXDkH85MoIPwM7tF5bvP8F4kx LPpv3Kx4QZNvIYAfLVriqn2D8btxbbhTbHBgcSahIiqugTYFZYwG3+xnJY89MS014vjL VU1+Ve92Rz89gwmjMQ62xrQ1+AencyBW+3mlkuIxhZNPHObQ7ddE9bcJEZNu4//uVZLd oy/g== X-Received: by 10.66.14.196 with SMTP id r4mr19624909pac.57.1374254876384; Fri, 19 Jul 2013 10:27:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 10:27:16 -0700 (PDT) In-Reply-To: <51E97677.1020902@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97677.1020902@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 10:27:16 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=bcaec51f99e5bd0b8404e1e0a559 X-Gm-Message-State: ALoCoQmEPoNBxWfpmKkJbg4TN3hkYho0h62U36tLPmeeqPVOG6qapNEK4aO/tNTKXg7ANLq/WvdzumKmwTKfryZ3zCqZ6ODHnkrgJ41ggzUTE0AAWcPglyM+AowMR+xPpMslH9o+hR3ScHyFnftJU3f+JqFACNNYOHB+08Mov32kY89hGmj6XlO+tgUorc071fEVRlCt5+RK Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:28:22 -0000 --bcaec51f99e5bd0b8404e1e0a559 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 10:25 AM, Adam Roach wrote: > On 7/19/13 12:07, Ted Hardie wrote: > > On Fri, Jul 19, 2013 at 9:54 AM, Martin Thomson wrote: > >> >> Negotiation is a hole. A vast, soul-sucking, waste of time. >> >> > Even if you have the same javascript application downloaded, you will have > disparate capabilities in the environments into which it is downloaded > (browser/os/codecs/media sources/available network capacity). Getting set > intersection and preference order for those capabilities is something that > applications actually want. You may be able to move the pain of that > around, but it isn't a waste of time. > > > I can't +1 this hard enough. I certainly don't want every javascript > application that makes use of the WebRTC API to independently discover that > mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to unusable > if you try to send it more than 320x200 video, and then try to solve that > problem. > > Again and again, for every permutation of phone and operating system > version. > > Yeah, someone has to do this kind of characterization, and some of it can > be done real-time if you're interacting directly with the operating system. > So... maybe we could add yet another API to WebRTC to allow applications to > build this functionality themselves rather than counting on them > characterizing the systems they care about and blowing up on the ones they > don't. > > But, honestly, any course of action that relegates this to the > applications seems to have the dual properties of forcing it to be > implemented hundreds of thousands of times while making the actual user > experience worse. > Hundreds of thousands of times? > > > /a > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec51f99e5bd0b8404e1e0a559 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 10:25 AM, Adam Roach <= adam@nostrum.com&= gt; wrote:
=20 =20 =20
On 7/19/13 12:07, Ted Hardie wrote:
On Fri, Jul 19, 2013 at 9:54 AM, Martin Thoms= on <martin.thomson@gmail.com> wrote:

Negotiation is a hole. =C2=A0A vast, soul-sucking, waste of time.=


Even if you have the same javascript application downloaded, you will have disparate capabilities in the environments into which it is downloaded (browser/os/codecs/media sources/available network capacity).=C2=A0 Getting set intersection and preference order for those capabilities is something that applications actually want.=C2= =A0 You may be able to move the pain of that around, but it isn't a waste of time.

I can't +1 this hard enough. I certainly don't want every javas= cript application that makes use of the WebRTC API to independently discover that mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to unusable if you try to send it more than 320x200 video, and then try to solve that problem.

Again and again, for every permutation of phone and operating system version.

Yeah, someone has to do this kind of characterization, and some of it can be done real-time if you're interacting directly with the operating system. So... maybe we could add yet another API to WebRTC to allow applications to build this functionality themselves rather than counting on them characterizing the systems they care about and blowing up on the ones they don't.

But, honestly, any course of action that relegates this to the applications seems to have the dual properties of forcing it to be implemented hundreds of thousands of times while making the actual user experience worse.

Hundreds o= f thousands of times?
=C2=A0
=


/a

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


--bcaec51f99e5bd0b8404e1e0a559-- From roman@telurix.com Fri Jul 19 10:29:50 2013 Return-Path: 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 10B6B21E80B6 for ; Fri, 19 Jul 2013 10:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 eV1TJEIRgpXr for ; Fri, 19 Jul 2013 10:29:45 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by ietfa.amsl.com (Postfix) with ESMTP id F24E811E8128 for ; Fri, 19 Jul 2013 10:29:34 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so4313168wev.14 for ; Fri, 19 Jul 2013 10:29:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vhYh3IBF5c/Dy4JAUrds8XewwbMC7oTrhvk/c8U7/Zg=; b=HVgWGk2olAqGgGLq6FqsgBLZZlNg95vwwXMfalweIum3Xzai7c0VqNyIA6xSRmbXv1 ZUGBsJYPhkyqfdN8gIcMZ/p6vgci+ewD7ZLYt93XUacnYcQNkdQ1WBlhg3bmmm3fMKWy Pq1SeYeUyRSwYej2Bkb8olSfN55uF6f7AZ+yZnW84z/6ssPIvjZwD03pI5r2V2g+Xuk/ Aw71NVTPVlUBz3qeMpnFoMAbc9VUHjjS54NQ26ZfgmUcMRtG5OUy173C2m+DESAVUk2F ri5uhS+zNHxfpqE+eVG5suZESahgdBKghFqpuKfN5WzuCi75mC3fMcbceQpTdZ6TK801 mCdQ== X-Received: by 10.180.187.235 with SMTP id fv11mr12102279wic.65.1374254972498; Fri, 19 Jul 2013 10:29:32 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [2a00:1450:400c:c03::22a]) by mx.google.com with ESMTPSA id f8sm4874798wiv.0.2013.07.19.10.29.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 10:29:31 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so4318077wes.15 for ; Fri, 19 Jul 2013 10:29:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.184.12 with SMTP id eq12mr2934957wic.8.1374254970717; Fri, 19 Jul 2013 10:29:30 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Fri, 19 Jul 2013 10:29:30 -0700 (PDT) In-Reply-To: <51E96B5B.2050302@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> Date: Fri, 19 Jul 2013 13:29:30 -0400 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=001a11c3669e5c4faf04e1e0ab5d X-Gm-Message-State: ALoCoQlGadchcGjuZNQv6LW6mM5JRqU5m3j7CmqlIvivPu5piVGpFH8HC7Yyq5QceMEW2cYz7rkp Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:29:50 -0000 --001a11c3669e5c4faf04e1e0ab5d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jul 19, 2013 at 12:37 PM, Adam Roach wrote: > I think this is a hopelessly na=EFve interpretation of the facts on the > ground. Simply discarding SDP doesn't magically make the underlying issue= s > go away. We would still need to settle a vast number of issues around > things like simulcast, FEC, codec parameters, indication of supported > codecs, correlation of RTP streams with MediaStreamTracks, attempts by bo= th > parties to operate on the same stream simultaneously [1], etc. Basically, > with very rare exception, the same set of problems that we need to solve = if > we *don't* throw SDP out the window. > I would argue that we are not as na=EFve as you think. First of all, a lot of the issues you are talking about are not yet solved. At the same time we have something already working and useful with current browser implementation. So, what we want is to have these features released as version 1.0. The problem that we face, that when you implement all the above mentioned features, even though the API will stay the same, SDP that it will produce will change, and that will require all, except the simplest application, and all external components interfacing WebRTC clients to change. And then when more features are implemented and more different versions are in use more and more interop for applications and external components will be required. What we want is an API that is not based on blob with unpredictable data. Second, offer/answer and SDP introduce a number of negotiation constraints that really should not be there. They cause unrelated things to be negotiated together. It should be possible to negotiate a data connection and then add and remove media streams without renegotiating the underlying data connection. To force selection of single codec you need to do two offer/answer exchanges, which caused by no other reason then framework limitations. Resolution of glare is restricted to offer back off. Furthermore, even from the point of view of offer/answer the current API is broken. It does not allow forking. It introduces a new PRANSWER which is not a part of normal offer/answer specification. It does not allow change send media parameters (ie change send codec or send codec parameters) without doing an offer/answer exchange, which is not necessary with normal offer/answer framework. So, what we are proposing is to map exiting implemented browser functionality to API and get rid of SDP. Ideally we should get rid of offer/answer as well but if it is too much work we can leave with it for version 1.0. This way we get predictable behavior based on predictable input. If we miss some of the future capabilities and they would require API modification to implement, we can deal with it in 2.0. In API, unlike network protocols, predictability and testability counts more then ability for future extension. _____________ Roman Shpount --001a11c3669e5c4faf04e1e0ab5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2013 at 12:37 PM, Adam Roach= <adam@nostrum.com> wrote:
I think this is a hopelessly na=EFve interpretation of the facts on the gro= und. Simply discarding SDP doesn't magically make the underlying issues= go away. We would still need to settle a vast number of issues around thin= gs like simulcast, FEC, codec parameters, indication of supported codecs, c= orrelation of RTP streams with MediaStreamTracks, attempts by both parties = to operate on the same stream simultaneously [1], etc. Basically, with very= rare exception, the same set of problems that we need to solve if we *don&= #39;t* throw SDP out the window.

I would argue that we are not as na=EFve a= s you think.

First of all, a lot of the issues you= are talking about are not yet solved. At the same time we have something a= lready working and useful with current browser implementation. So, what we = want is to have these features released as version 1.0. The problem that we= face, that when you implement all the above mentioned features, even thoug= h the API will stay the same, SDP that it will produce will change, and tha= t will require all, except the simplest application, and all external compo= nents interfacing WebRTC clients to change. And then when more features are= implemented and more different versions are in use more and more interop f= or applications and external components will be required. What we want is a= n API that is not based on blob with unpredictable data.

Second, offer/answer and SDP introduce a number of nego= tiation constraints that really should not be there. They cause unrelated t= hings to be negotiated together. It should be possible to negotiate a data = connection and then add and remove media streams without renegotiating the = underlying data connection. To force selection of single codec you need to = do two offer/answer exchanges, which caused by no other reason then framewo= rk limitations. Resolution of glare is restricted to offer back off. Furthe= rmore, even from the point of view of offer/answer the current API is broke= n. It does not allow forking. It introduces a new PRANSWER which is not a p= art of normal offer/answer specification. It does not allow change send med= ia parameters (ie change send codec or send codec parameters) without doing= an offer/answer exchange, which is not necessary with normal offer/answer = framework.=A0

So, what we are proposing is to map exiting implemented= browser functionality to API and get rid of SDP. Ideally we should get rid= of offer/answer as well but if it is too much work we can leave with it fo= r version 1.0. This way we get predictable behavior based on predictable in= put. If we miss some of the future capabilities and they would require API = modification to implement, we can deal with it in 2.0. In API, unlike netwo= rk protocols, predictability and testability counts more then ability for f= uture extension.=A0
_____________=A0
Roman Shpount=A0
--001a11c3669e5c4faf04e1e0ab5d-- From adam@nostrum.com Fri Jul 19 10:31:19 2013 Return-Path: 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 F41E911E8147 for ; Fri, 19 Jul 2013 10:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 X3MxkJnrARPz for ; Fri, 19 Jul 2013 10:31:18 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5F411E80FD for ; Fri, 19 Jul 2013 10:31:18 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JHVCxL075152 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 12:31:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E977DB.5010002@nostrum.com> Date: Fri, 19 Jul 2013 12:31:07 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Thatcher References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97677.1020902@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040208060104080403030705" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:31:19 -0000 This is a multi-part message in MIME format. --------------040208060104080403030705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/19/13 12:27, Peter Thatcher wrote: > > But, honestly, any course of action that relegates this to the > applications seems to have the dual properties of forcing it to be > implemented hundreds of thousands of times while making the actual > user experience worse. > > > Hundreds of thousands of times? > How many web apps do you anticipate will use real time communications between now and the time that this work becomes obsolete? It's not important to come to consensus on this number -- my key point here is that it's significantly more than the number of web browsers that will be developed in that time, and by several orders of magnitude. /a --------------040208060104080403030705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/19/13 12:27, Peter Thatcher wrote:

But, honestly, any course of action that relegates this to the applications seems to have the dual properties of forcing it to be implemented hundreds of thousands of times while making the actual user experience worse.

Hundreds of thousands of times?
 

How many web apps do you anticipate will use real time communications between now and the time that this work becomes obsolete?

It's not important to come to consensus on this number -- my key point here is that it's significantly more than the number of web browsers that will be developed in that time, and by several orders of magnitude.

/a
--------------040208060104080403030705-- From adam@nostrum.com Fri Jul 19 10:35:08 2013 Return-Path: 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 650F521E8050 for ; Fri, 19 Jul 2013 10:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 5OpOcT6HOA5T for ; Fri, 19 Jul 2013 10:35:08 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CBD7F11E80E3 for ; Fri, 19 Jul 2013 10:35:07 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JHZ4sf075527 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 12:35:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E978C2.8000002@nostrum.com> Date: Fri, 19 Jul 2013 12:34:58 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roman Shpount References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:35:08 -0000 On 7/19/13 12:29, Roman Shpount wrote: > First of all, a lot of the issues you are talking about are not yet > solved. That was my *point*. /a From martin.thomson@gmail.com Fri Jul 19 10:37:22 2013 Return-Path: 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 79AC721E8100 for ; Fri, 19 Jul 2013 10:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, 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 On4uFbxnWPr1 for ; Fri, 19 Jul 2013 10:37:22 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D3AC421E80DF for ; Fri, 19 Jul 2013 10:37:21 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so4315364wes.32 for ; Fri, 19 Jul 2013 10:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r4mbcoU2txfazp+OtA/lotXwudELebD+nA3UPXra8P4=; b=KuqCqfHlNH+jfe4YBjDCez7YhUWEhKfpdLdPVyXmjn23wiedF5Kj6AxZNTqSBL4OoG blcxwI0oEli42DpWu8HA2JOqX3YgQPoziTCa6QK967Q5akwe5OaYT0LznCARgglk8D9U Lj3aHSeycJFIyoPE7YI24XECNRYRyur9u1Uj/FbNre++3JCA7ghhbjvS68RDPhNXcVUf tlS8saS4Xo1i+IGbgd38qxH1x1AkBxbwpsNciHzW+m4xH0EbDm6ID61crxVFOgifmFmD HQMYLd2NngYFKWL5v17fcBiMsiIaffhxC7Gu4ugmRmvWbKA/8bTfY/lZoNA5hTCMXgvw EQlQ== MIME-Version: 1.0 X-Received: by 10.180.73.68 with SMTP id j4mr23535892wiv.10.1374255440956; Fri, 19 Jul 2013 10:37:20 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 19 Jul 2013 10:37:20 -0700 (PDT) In-Reply-To: <51E978C2.8000002@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E978C2.8000002@nostrum.com> Date: Fri, 19 Jul 2013 10:37:20 -0700 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:37:22 -0000 On 19 July 2013 10:34, Adam Roach wrote: > On 7/19/13 12:29, Roman Shpount wrote: >> >> First of all, a lot of the issues you are talking about are not yet >> solved. > > That was my *point*. So what, the logical conclusion is to tell people that are working on (or have proposed) solutions to go away because they don't fit with your preconceptions about what a solution should look like? From roman@telurix.com Fri Jul 19 10:37:47 2013 Return-Path: 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 D95B021E80C7 for ; Fri, 19 Jul 2013 10:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 WHYm0Ej8Aw-2 for ; Fri, 19 Jul 2013 10:37:41 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0A021E8108 for ; Fri, 19 Jul 2013 10:37:36 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so4325699wes.34 for ; Fri, 19 Jul 2013 10:37:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=y6HFwPjrd2JYT8Lx5dTu+sebBuwzjJ5+ior62uPE2pY=; b=nBXCA54ZCB7u6xy8/qj7UMlZtRUGJRyCJP8ApBZNYMiSsV9Hy8loPB7RaZLttmQv/g hV6ZwTFWsWaftunSr3b7ZnUBp5GNJfqQpuusMskv6dDEtr344LBGLWm9d1NhdtRj01gP cN8BZBE59s47+KTFGEQYpUb3+fjQCdTWpgoXzdR6Ehy0ZTl+J0p06Nxw6k0KpKtRyKrJ 6HTYaBZhX+MmxF66MTV3RSHsjeadeGDgoD5FByJfvmB9j12O35UvIGgc8N01gfsnEGei QC2tH4NXEb6imRFDPiffA6hR2enAqtxVM3ktb6RHhwdc+culFIO5CSdWxnbR3qVoJM0f 0N1A== X-Received: by 10.194.83.195 with SMTP id s3mr13092913wjy.82.1374255455516; Fri, 19 Jul 2013 10:37:35 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [2a00:1450:400c:c00::230]) by mx.google.com with ESMTPSA id b20sm24460029wiw.4.2013.07.19.10.37.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 10:37:34 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so4234535wgh.27 for ; Fri, 19 Jul 2013 10:37:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.173.71 with SMTP id bi7mr12898105wjc.2.1374255454006; Fri, 19 Jul 2013 10:37:34 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Fri, 19 Jul 2013 10:37:33 -0700 (PDT) In-Reply-To: <51E97677.1020902@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97677.1020902@nostrum.com> Date: Fri, 19 Jul 2013 13:37:33 -0400 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=089e0112cf9a2ad3f304e1e0c8ce X-Gm-Message-State: ALoCoQlPbxa0Sc3mmGRbZXDT6yj8oBnGPvI7fKFyV5MuiMhFlXjSy9EIY+UKYKwyKQj91MuHEw2J Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:37:47 -0000 --089e0112cf9a2ad3f304e1e0c8ce Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 1:25 PM, Adam Roach wrote: > I can't +1 this hard enough. I certainly don't want every javascript > application that makes use of the WebRTC API to independently discover that > mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to unusable > if you try to send it more than 320x200 video, and then try to solve that > problem. > > Again and again, for every permutation of phone and operating system > version. > > Yeah, someone has to do this kind of characterization, and some of it can > be done real-time if you're interacting directly with the operating system. > So... maybe we could add yet another API to WebRTC to allow applications to > build this functionality themselves rather than counting on them > characterizing the systems they care about and blowing up on the ones they > don't. > > But, honestly, any course of action that relegates this to the > applications seems to have the dual properties of forcing it to be > implemented hundreds of thousands of times while making the actual user > experience worse. > You cannot be more wrong. Each application deals with predictable set of scenarios (ones it produces) and interfaces with predictable set of non webrtc devices. These external devices are under control of the application developer. Application developer is responsible for interop with these devices. What is needed is predictable media and signaling generated by webrtc devices running the same application. With negotiation and SDP backed into the webrtc device it is very hard to achieve. So, for me as webrtc developer let me develop a negotiation scheme that works for me and make sure it stay working regardless of the browser type or version. Right now controlling webrtc application feels like driving the boat down the river by tickling the captain. _____________ Roman Shpount --089e0112cf9a2ad3f304e1e0c8ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2013 at 1:25 PM, Adam Roach <ada= m@nostrum.com> wrote:
=20 =20 =20
I can't +1 this hard enough. I certainly don't want every = javascript application that makes use of the WebRTC API to independently discover that mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to unusable if you try to send it more than 320x200 video, and then try to solve that problem.

Again and again, for every permutation of phone and operating system version.

Yeah, someone has to do this kind of characterization, and some of it can be done real-time if you're interacting directly with the operating system. So... maybe we could add yet another API to WebRTC to allow applications to build this functionality themselves rather than counting on them characterizing the systems they care about and blowing up on the ones they don't.

But, honestly, any course of action that relegates this to the applications seems to have the dual properties of forcing it to be implemented hundreds of thousands of times while making the actual user experience worse.

You cannot= be more wrong. Each application deals with predictable set of scenarios (o= nes it produces) and interfaces with predictable set of non webrtc devices.= These external devices are under control of the application developer. App= lication developer is responsible for interop with these devices. What is n= eeded is predictable media and signaling generated by webrtc devices runnin= g the same application. With negotiation and SDP backed into the webrtc dev= ice it is very hard to achieve. So, for me as webrtc developer let me devel= op a negotiation scheme that works for me and make sure it stay working reg= ardless of the browser type or version. Right now controlling webrtc applic= ation feels like driving the boat down the river by tickling the captain.
_____________
Roman Shpount
=A0
--089e0112cf9a2ad3f304e1e0c8ce-- From pthatcher@google.com Fri Jul 19 10:38:22 2013 Return-Path: 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 8DB6B21E80DF for ; Fri, 19 Jul 2013 10:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.243, 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 vxzGfzuNb5lD for ; Fri, 19 Jul 2013 10:38:22 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9877E21E805D for ; Fri, 19 Jul 2013 10:38:12 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rl6so4719354pac.1 for ; Fri, 19 Jul 2013 10:38:12 -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=wbYZ8f+09h3ZTVUD2N60rza86G5gd/7k0R3xkBD/x6c=; b=As5Lk09HQc5BYusiLDhonuUtcUUcyunSYNlwGzTxyk7tjHJppobxlMMbDPi9qsOAFu 5zDP86+ppQbVyLk55QfQKOUAFfsFKU7ClzE+4i5+IvyExNMC8SDYb00YfQT8PxU32wWe qkF5Omj9s6AR7oZKnrGOqQSt0W1oSmcp3XzyF1tFHIOo3ATyUy7NST6QRW2N+/kCXtBg 0xl352o8EgkgeiiGy9u/8vo0HxzXE66ssLtXhCOH5mWdhjg8YusPO81POeBRdT6Kh9XU RWbejJSwBStb7pBh9qayxSdpiNbSxSfUwBRgMx1I3S6lXJkveyH9SC0uJGsuPuxxoYmm zNPg== 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=wbYZ8f+09h3ZTVUD2N60rza86G5gd/7k0R3xkBD/x6c=; b=CIIe1bP7YOJly6Eeuq2C2hgisfiVRDhQN4ad6BYw5YqMSIkC1ISRLBWtRLf595pquR F4aXEsCDyQX9Jz13SJIGXezNlCvVa5JPctwrKdrINxKRmi5Y1BZDz17ymDNNI4XlIZwd 2rjp6GbwZnf29SHBHKpaun6K11bF4ewpp9lUyG/22OG6lE9iOxs/KzK5lN0iT+dKZjmk 8F+/iYwJh5yd9BUNqnr908KvbjgkTQWwvRK2s0P7UOGIuFzfkG/szbW+ujWYTAjSyZUE PuOMSw7JM3Zk8GMtXZkTvDXvIzEhfQRwfIxjVfuI0DAsmPU/0Jp2wHA8DUXARiRXTQSV 0TRQ== X-Received: by 10.66.4.6 with SMTP id g6mr9424791pag.96.1374255492272; Fri, 19 Jul 2013 10:38:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 10:37:31 -0700 (PDT) In-Reply-To: <51E977DB.5010002@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97677.1020902@nostrum.com> <51E977DB.5010002@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 10:37:31 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=bcaec520e9f772be3404e1e0ca00 X-Gm-Message-State: ALoCoQnqk91ux5BQ5gp9KqWh1sa1LbhCsQN6TCaLUiUyLN4tAOrC3qnBEpOUH6WTqlpLGI2+cWIhJo9azsVhs9oFW19ZEZffcYp/GYrEzwVCfXXtIGalmA1jYrxLMl1ukyOXg+S/q8uHljcXzTNCto4Skv/CeEODADpwSP+yEkVJSZM9pwougFVSYept0l0R4PUMJk6g+SmF Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:38:22 -0000 --bcaec520e9f772be3404e1e0ca00 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 10:31 AM, Adam Roach wrote: > On 7/19/13 12:27, Peter Thatcher wrote: > > > But, honestly, any course of action that relegates this to the >> applications seems to have the dual properties of forcing it to be >> implemented hundreds of thousands of times while making the actual user >> experience worse. >> > > Hundreds of thousands of times? > > > > How many web apps do you anticipate will use real time communications > between now and the time that this work becomes obsolete? > That's an excellent point. Along with that, how many will only be using the data channel? And how many will be using something other than SDP for signalling? And how many will be doing lots of SDP munging? And how many libraries will be written to hide the ugliness of SDP? Hundreds of thousands? > > It's not important to come to consensus on this number -- my key point > here is that it's significantly more than the number of web browsers that > will be developed in that time, and by several orders of magnitude. > That's an excellent point. If we spent a little bit of extra work making a really good API, think of how many people will benefit. It's several orders of magnitude more than the number of web browser that will need to do a little bit of extra work to implement a good API. > > > /a > --bcaec520e9f772be3404e1e0ca00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 10:31 AM, Adam Roach <= adam@nostrum.com&= gt; wrote:
=20 =20 =20
On 7/19/13 12:27, Peter Thatcher wrote:

But, honestly, any course of action that relegates this to the applications seems to have the dual properties of forcing it to be implemented hundreds of thousands of times while making the actual user experience worse.

Hundreds of thousands of times?
=C2=A0

How many web apps do you anticipate will use real time communications between now and the time that this work becomes obsolete?

That's an excel= lent point. =C2=A0Along with that, how many will only be using the data cha= nnel? =C2=A0And how many will be using something other than SDP for signall= ing? =C2=A0And how many will be doing lots of SDP munging? =C2=A0And how ma= ny libraries will be written to hide the ugliness of SDP? =C2=A0Hundreds of= thousands?
=C2=A0

It's not important to come to consensus on this number -- my key point here is that it's significantly more than the number of web browsers that will be developed in that time, and by several orders of magnitude.

That's an excel= lent point. =C2=A0If we spent a little bit of extra work making a really go= od API, think of how many people will benefit. =C2=A0It's several order= s of magnitude more than the number of web browser that will need to do a l= ittle bit of extra work to implement a good API. =C2=A0
=C2=A0


/a

--bcaec520e9f772be3404e1e0ca00-- From roman@telurix.com Fri Jul 19 10:39:21 2013 Return-Path: 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 AE28221F9D71 for ; Fri, 19 Jul 2013 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 6RaeXhYWgBAh for ; Fri, 19 Jul 2013 10:39:16 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBDE21F8415 for ; Fri, 19 Jul 2013 10:38:56 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so65972wiw.17 for ; Fri, 19 Jul 2013 10:38:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=AjfRruU+is5uRSKPt8r894u4ZSPyRSl51SgPxKfi8XA=; b=UMePftjG+p609yULGvnhvLoix3/6ErppT5ULk8CSTlQs9dEQkAJz2cnfl8YJki2xZm i7X9bki43zHGhGm39loj6tEMK1S6H7thJy1a9fENWxnjsWNL9wu9vEL8jSTpk3AKB4kP aBd2tlNQYeNS3bhBhO8sisspKGXPgs1Jt7xFkVuvb/irs5HMUSQouTLyfyWdbpYA9yhI +Q+CtKsG8Hi5VN1Z0567aKcn96mxGXayFCM7Raz3zmkgTsoil7GRP5lK+k1/+VZZ58K3 0283uSpkZViysThJ6rgO1epdBLxBfnW2iEoHV6xm64re+Hx0nbw7pAlXoMjmW9uT/w5s 0UXA== X-Received: by 10.180.96.73 with SMTP id dq9mr12231416wib.51.1374255535375; Fri, 19 Jul 2013 10:38:55 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [2a00:1450:400c:c05::233]) by mx.google.com with ESMTPSA id fb9sm49846674wid.2.2013.07.19.10.38.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 10:38:54 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so68349wib.12 for ; Fri, 19 Jul 2013 10:38:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.185.133 with SMTP id fc5mr23051745wic.8.1374255530323; Fri, 19 Jul 2013 10:38:50 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Fri, 19 Jul 2013 10:38:50 -0700 (PDT) In-Reply-To: <51E978C2.8000002@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E978C2.8000002@nostrum.com> Date: Fri, 19 Jul 2013 13:38:50 -0400 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=001a11c355feb738e304e1e0cc64 X-Gm-Message-State: ALoCoQnSzY9yLboZ96yEMEKKb1yzaEVKGyGGqQAc3zL3mMWwkNiOtdErwGCPpw35FieepTlNK4oS Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:39:21 -0000 --001a11c355feb738e304e1e0cc64 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 1:34 PM, Adam Roach wrote: > On 7/19/13 12:29, Roman Shpount wrote: > >> First of all, a lot of the issues you are talking about are not yet >> solved. >> > > That was my *point*. > > And my point is that each time you solve any of those issue you will break all the applications working so far. Not a good API design. _____________ Roman Shpount --001a11c355feb738e304e1e0cc64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 19, 2013 at 1:34 PM, = Adam Roach <adam@nostrum.com> wrote:
On 7/19/13 12:29, Roman Shpount wrote:
First of all, a lot of the issues you are talking about are not yet solved.=

That was my *point*.


And my point is that eac= h time you solve any of those issue you will break all the applications wor= king so far. Not a good API design.
_____________
Roman Shpoun= t
=A0
--001a11c355feb738e304e1e0cc64-- From pthatcher@google.com Fri Jul 19 10:40:52 2013 Return-Path: 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 3F15121E805D for ; Fri, 19 Jul 2013 10:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 M-gMEgDxaKMb for ; Fri, 19 Jul 2013 10:40:51 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1EC11E80E3 for ; Fri, 19 Jul 2013 10:40:49 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so4686814pbc.24 for ; Fri, 19 Jul 2013 10:40:48 -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=+exL9caBwGmUnE1nX3MWE/4mcq8+2YkO9rvRFdeoDXE=; b=HksWwjNDMwl2Q+DfG8+0Mu4QHokGs5L7/mP9ooMcG6dIIqt0QKfPEgxf4F6oDotvX6 KVJZ2ZuTMTggEtFpjIQIemjOWPScWRVE68Z1La2uCsfbLiOHNxgMOdtUWM7B29rZiyQj 7uWy4UHskMVtvzJDAD7+dICwzzcv0Yg4exZvqGsmt1xdl/ynU5mJqB/DXA4gg3fbmp4D dw+ocrKq7Su9+3DHD89QodiKynkcYyb8S/zDHaYr1zPb210gaZJLlxexMBEE9N8OTol6 1k2VaZqaXotiipZNFYY7EI/eW9boAgx+0TnTII8gOfxboas9/LjWOGAj7OZNo6Oi99WN KYvg== 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=+exL9caBwGmUnE1nX3MWE/4mcq8+2YkO9rvRFdeoDXE=; b=JCsKzEgZC8i4Om1GKk6Zi4pIFJDQJXv6zaUI1RDQShqYNASBFHnjawBkHvp8CYksp/ g4fCsvRbDSl0Di+WUXlVeK/QnUoQhPuh6Qf2FY1Qx/h1gLquDq0BN5IgR+nQ8i4zUNfr DvWdYWJSYnx9KpbhluxGPd+DylCPvtbaRYpXd0wYGehnmFbX4zSuQtTq+Ay6xOwgBT33 Bx4DKoJ3DcqoXfZkHIRFq8UPX0KQ6vBScMEst4nh1P19ncVakPvHHFghMMOegiko14YJ Bh3DoFLOgP05IlX1cLyE4+RcM8nIypJJ/mM1LnXZsiXFgH37XKeVkOOTbGXvtjkYNMFP PATQ== X-Received: by 10.68.29.2 with SMTP id f2mr18320541pbh.184.1374255648856; Fri, 19 Jul 2013 10:40:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 10:39:43 -0700 (PDT) In-Reply-To: <51E978C2.8000002@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E978C2.8000002@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 10:39:43 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=bcaec520f3b9c820a904e1e0d36e X-Gm-Message-State: ALoCoQmTt+TxDvM5oDeV+RhufuoSb2Ky/vcl9f3qpozKW2DTaf+fvyUsCNbeGmu5omDrN/pw0CAa1X6wDqBnlug0dQ9r9OBupF/pCtTlQQaowqPZNJFmWlNnI+iqvPKBCjlBs9MsgWq4j3JA1ofGaqIgr7yERbzcy3yZPRvPwVuSYESjx3JC3S4ImYu1bDfmeMyfZbjV7bW+ Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:40:52 -0000 --bcaec520f3b9c820a904e1e0d36e Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 10:34 AM, Adam Roach wrote: > On 7/19/13 12:29, Roman Shpount wrote: > >> First of all, a lot of the issues you are talking about are not yet >> solved. >> > > That was my *point*. > > So, are you trying to say "Look how hard this is to do with SDP. We're not even done yet. It will be even harder without SDP"? > /a > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec520f3b9c820a904e1e0d36e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 10:34 AM, Adam Roach <= adam@nostrum.com&= gt; wrote:
On 7/19/13 12:29, Roman Sh= pount wrote:
First of all, a lot of the issues you are talking about are not yet solved.=

That was my *point*.


So, are you trying to sa= y "Look how hard this is to do with SDP. =C2=A0We're not even done= yet. =C2=A0It will be even harder without SDP"?
=C2=A0
/a

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

--bcaec520f3b9c820a904e1e0d36e-- From adam@nostrum.com Fri Jul 19 10:50:15 2013 Return-Path: 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 5239821E80D3 for ; Fri, 19 Jul 2013 10:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 w3GbjAmrWT-j for ; Fri, 19 Jul 2013 10:50:14 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A81821E80B6 for ; Fri, 19 Jul 2013 10:50:08 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JHnweR077272 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 12:49:59 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E97C41.5050208@nostrum.com> Date: Fri, 19 Jul 2013 12:49:53 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Thatcher References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:50:16 -0000 On 7/19/13 12:18, Peter Thatcher wrote: > Please try to consider what you sound like to a web developer who is > trying to use WebRTC and finding SDP to be difficult API surface. I think any time someone says they've used the SDP directly as a control surface in a JavaScript application, it indicates a hole in the current WebRTC specification that we need to fix. SDP is not supposed to be the WebRTC API surface. I think we all pretty much agree that SDP is not supposed to be the WebRTC API surface. I think we're pretty much all on the same page that we need to add stuff to the current API to handle these use cases. > Maybe I'm wrong, but I'm guessing what you're saying will sound like. > "my use case (legacy interop) is the most important and my solution > (SDP) is the best solution for everyone and I know better because I've > been working on it for longer". Hubris? No, you've misunderstood pretty much everything I said. I'll summarize in fewer words. My point is that we need to solve these problems one way or another, and SDP isn't really the reason it's difficult. But by incorrectly deciding that SDP (or offer/answer, depending on who you listen to) is the reason it's hard, we're trying to throw legacy interop out the window for very little gain. And, while not the only (or even main) consideration, legacy interop has significant value. It would be a shame to destroy that value based on a misconception. These issues aren't hard because of SDP. These issues are hard because they're hard. /a From adam@nostrum.com Fri Jul 19 10:51:12 2013 Return-Path: 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 AF1A311E8169 for ; Fri, 19 Jul 2013 10:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ysWtRFmG1xp1 for ; Fri, 19 Jul 2013 10:51:12 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BF96511E80E3 for ; Fri, 19 Jul 2013 10:51:10 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JHp77A077499 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 12:51:07 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E97C86.2090808@nostrum.com> Date: Fri, 19 Jul 2013 12:51:02 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Thatcher References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E978C2.8000002@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:51:12 -0000 On 7/19/13 12:39, Peter Thatcher wrote: > > So, are you trying to say "Look how hard this is to do with SDP. > We're not even done yet. It will be even harder without SDP"? > No. I'm not saying it would be harder. I'm saying it wouldn't be easier, and you would lose tangible benefits. /a From roman@telurix.com Fri Jul 19 10:55:28 2013 Return-Path: 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 D731111E8171 for ; Fri, 19 Jul 2013 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 aUV4q1pHtlrz for ; Fri, 19 Jul 2013 10:55:23 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id D355221E80B8 for ; Fri, 19 Jul 2013 10:55:07 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so4330096wes.32 for ; Fri, 19 Jul 2013 10:55:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=LXTx1HWtZpY9Hb2/m7XZ0ALtElnZgvrty2Fx9T2Ory4=; b=Xj0SzC511H+XWFKwyymUYcB+AdrSrxzC2/QwWjWCZ2C137qcYBjBbMRynidjakGwxZ 3jgGZe5lhu4Jy0grtkGoWVEMCxUsbQXssr61NyqOv29XU/nseR/W5GY0N5R7Bk56uvQM pwhtmTKatMJjVy3aWU/9YeancF1/9TFpxz3ezc5IbQkAxxTrOlcGJCpFphIbZylk5vyo b5yS2EEXzqslWK0snzLoz+KLla3NFVv0SNtDs3/9PTSNUN8WcpuDew46uMkgo4ucm8YA 6UbzShtZYdLxK42EqoqTR4gPdNJAzpkoP+/hP0a8jg2/fVPeKsKBUeUXUi8W30bgIV/H 4HJg== X-Received: by 10.180.211.233 with SMTP id nf9mr12281443wic.41.1374256504891; Fri, 19 Jul 2013 10:55:04 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [2a00:1450:400c:c00::22b]) by mx.google.com with ESMTPSA id fd3sm49930726wic.10.2013.07.19.10.55.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 10:55:04 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so4249334wgg.10 for ; Fri, 19 Jul 2013 10:55:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr12161650wic.65.1374256502402; Fri, 19 Jul 2013 10:55:02 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Fri, 19 Jul 2013 10:55:02 -0700 (PDT) In-Reply-To: <51E97C41.5050208@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97C41.5050208@nostrum.com> Date: Fri, 19 Jul 2013 13:55:02 -0400 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=001a11c25aa0a7f79404e1e1067c X-Gm-Message-State: ALoCoQnQoINsPSmapgvdi4skkBkJfBcDFLhenMZRwMh8mT2pnmegdAyBdrkEzRvvUZfW0C/fap10 Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:55:29 -0000 --001a11c25aa0a7f79404e1e1067c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 1:49 PM, Adam Roach wrote: > > These issues aren't hard because of SDP. These issues are hard because > they're hard. > > I agree that those issues are hard but with SDP they are harder. SDP requires to create solutions that are backwards compatible within a very restrictive framework. API allows solutions that are backwards compatible if they are coded specific way. This is a huge difference. _____________ Roman Shpount --001a11c25aa0a7f79404e1e1067c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2013 at 1:49 PM, Adam Roach <adam@nostrum.com><= /span> wrote:

These issues aren't hard because of SDP. These issues are hard because = they're hard.


I agree that those issue= s are hard but with SDP they are harder. SDP requires to create solutions t= hat are backwards compatible within a very restrictive framework. API allow= s solutions that are backwards compatible if they are coded specific way. T= his is a huge difference.
_____________
Roman Shpount
=A0
--001a11c25aa0a7f79404e1e1067c-- From martin.thomson@gmail.com Fri Jul 19 10:58:07 2013 Return-Path: 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 3008611E80E3 for ; Fri, 19 Jul 2013 10:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, 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 aFtxjzPZIyC4 for ; Fri, 19 Jul 2013 10:58:06 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 67B7B21E80DC for ; Fri, 19 Jul 2013 10:58:03 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so82738wiw.17 for ; Fri, 19 Jul 2013 10:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B5TLJiMVsumn9hNXrfyvKdCg4UVOXv+Fk0iF8OGV3Xw=; b=bLvQOKrTpDJMTIKuFqXdD+VC3/gz53204u7Rhvo5PrSKX/sxNclTCXteT8so640CHe JuN14ZAAJdpFCUjT8g1vCaYemy8DtdHS63tcEDbH3ldCyoFKbEJzqgP7Cz8XbsqzTqlo rLvJ9uKCMHjF0m3RfIiyhR/5IHx/62kz00GcmVTYPmrBGHnNRsI0QxrGRRdYuu1Tq/j3 BWWOJvCofKVNfaHEGlxmGEsi6rHpgKWIicy1B6BJRWuFvA2RtfGBUVqbjxrQV4dig1vk ecCYpkKuFLp9eI5iT8JKz5wiRkTqtDnX2DHbyqMBmHrWkPB/Sy89kUYkKcIfact/e8H/ +byQ== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr12947251wjx.84.1374256675056; Fri, 19 Jul 2013 10:57:55 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 19 Jul 2013 10:57:54 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E978C2.8000002@nostrum.com> Date: Fri, 19 Jul 2013 10:57:54 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:58:07 -0000 On 19 July 2013 10:39, Peter Thatcher wrote: > So, are you trying to say "Look how hard this is to do with SDP. We're not > even done yet. It will be even harder without SDP"? In the Atlanta meeting (Nov 2012) I remember waiting for those damned elevators with Justin. He said something like: "So, if we'd chosen comment 22 [CU-RTC-Web] do you think we'd be done by now?" I was quick to answer, "Of course not." After all, we'd only made that proposal 3-4 months earlier. I know that nothing gets done in less than a year, and this is not a small undertaking. Since then, I've gained a more nuanced view. We've set an impossibly high bar for this specification, including all sorts of crazy features: FEC, simulcast, layered codecs, congestion control, undeployed codecs, multiplexing, and not to mention a new data channel. In reality, SDP never negotiated all that crap before. Worse, despite the existence of RFCs for most of these features, it turns out that most implementations were proprietary. We couldn't even agree on what an m-line represents. So, if asked the same question today, I'd probably have to say: "We'd at least have had basic scenarios shipped. We might not have sorted out the hard cases like layered codecs, but we do have basic functionality." What we have this the complete antithesis of any project I've been involved in over the past 10 years. It's gold-plating the pink squirrel. If we want to ship this thing, then we should be managing scope, not protecting it. From matthew.kaufman@skype.net Fri Jul 19 11:25:32 2013 Return-Path: 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 947C411E816E for ; Fri, 19 Jul 2013 11:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=-0.477, 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 CYxqlJ6lYlJe for ; Fri, 19 Jul 2013 11:25:26 -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 99F1021F9D24 for ; Fri, 19 Jul 2013 11:25:23 -0700 (PDT) Received: from mail165-db9-R.bigfish.com (10.174.16.230) by DB9EHSOBE029.bigfish.com (10.174.14.92) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 18:25:22 +0000 Received: from mail165-db9 (localhost [127.0.0.1]) by mail165-db9-R.bigfish.com (Postfix) with ESMTP id 1A8963A0159; Fri, 19 Jul 2013 18:25:22 +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: -1 X-BigFish: VS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail165-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=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail165-db9 (localhost.localdomain [127.0.0.1]) by mail165-db9 (MessageSwitch) id 1374258319427401_7385; Fri, 19 Jul 2013 18:25:19 +0000 (UTC) Received: from DB9EHSMHS007.bigfish.com (unknown [10.174.16.239]) by mail165-db9.bigfish.com (Postfix) with ESMTP id 626AF16008E; Fri, 19 Jul 2013 18:25:19 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS007.bigfish.com (10.174.14.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 19 Jul 2013 18:25:17 +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 18:25:14 +0000 From: "Matthew Kaufman (SKYPE)" To: Adam Roach , Peter Thatcher 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: AQHOhKQOxbdxSe2FO0i0LZeMXs0KIJlsR3aAgAAHKxA= Date: Fri, 19 Jul 2013 18:25:13 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97C41.5050208@nostrum.com> In-Reply-To: <51E97C41.5050208@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:25:32 -0000 QWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dDQo+DQo+IEkgdGhpbmsgYW55IHRp bWUgc29tZW9uZSBzYXlzIHRoZXkndmUgdXNlZCB0aGUgU0RQIGRpcmVjdGx5IGFzIGEgY29udHJv bA0KPiBzdXJmYWNlIGluIGEgSmF2YVNjcmlwdCBhcHBsaWNhdGlvbiwgaXQgaW5kaWNhdGVzIGEg aG9sZSBpbiB0aGUgY3VycmVudCBXZWJSVEMNCj4gc3BlY2lmaWNhdGlvbiB0aGF0IHdlIG5lZWQg dG8gZml4Lg0KPiANCj4gU0RQIGlzIG5vdCBzdXBwb3NlZCB0byBiZSB0aGUgV2ViUlRDIEFQSSBz dXJmYWNlLg0KDQpCdXQgaXQgaXMsIGF0IGxlYXN0IGluIHNvbWUgc2Vuc2UsIGV2ZW4gaWYgd2Ug Y29tZSB1cCB3aXRoIGxvdHMgb2YgY29uc3RyYWludCBBUElzLg0KDQo+IA0KPiBJIHRoaW5rIHdl IGFsbCBwcmV0dHkgbXVjaCBhZ3JlZSB0aGF0IFNEUCBpcyBub3Qgc3VwcG9zZWQgdG8gYmUgdGhl IFdlYlJUQw0KPiBBUEkgc3VyZmFjZS4NCg0KTm90IHN1cmUgYWJvdXQgdGhhdCwgYnV0IHN1cHBv c2UgdGhhdCdzIHRydWUgZm9yIGEgbW9tZW50Li4uDQoNCj4gDQo+IEkgdGhpbmsgd2UncmUgcHJl dHR5IG11Y2ggYWxsIG9uIHRoZSBzYW1lIHBhZ2UgdGhhdCB3ZSBuZWVkIHRvIGFkZCBzdHVmZiB0 bw0KPiB0aGUgY3VycmVudCBBUEkgdG8gaGFuZGxlIHRoZXNlIHVzZSBjYXNlcy4NCg0KDQpCdXQg aG93IGNhbiB3ZSBwb3NzaWJseSBhZGQgc3R1ZmYgdG8gdGhlIGN1cnJlbnQgQVBJIHRoYXQgcnVu cyBkaXJlY3RseSBjb3VudGVyIHRvIHRoZSBmYWN0IHRoYXQgMSkgdGhlIHR3byBicm93c2VycyBh cmUgYXR0ZW1wdGluZyB0byBuZWdvdGlhdGUgdGhpbmdzIHdpdGggb25lIGFub3RoZXIgb3ZlciBh biBTRFAtYmFzZWQgY2hhbm5lbCBpbnN0ZWFkIG9mIGRvaW5nIHdoYXQgdGhlIGFwcGxpY2F0aW9u IGRldmVsb3BlciB0ZWxscyB0aGVtIHRvIGRvIGFuZCAyKSBiZWNhdXNlIHRoYXQgbmVnb3RpYXRp b24gaXMgYmFzZWQgb24gb2ZmZXItYW5zd2VyLCB0aGVyZSBpcyBhIHN0YXRlIG1hY2hpbmUgdGhh dCB3aWxsIHByb2hpYml0IG9yIGFsbG93IGNlcnRhaW4gc3RhdGUgdHJhbnNpdGlvbnMgYXQgdmFy aW91cyB0aW1lcyBpbiB0aGUgcHJvY2Vzcz8NCg0KVGhpcyBpcyBhIHNlcmlvdXMgcHJvYmxlbS4g QXMgbG9uZyBhcyB3ZSBhc3N1bWUgdGhhdCB0aGVyZSBpcyBhbiBBUEkgdGhhdCBlbWl0cyBTRFAg dGhhdCBpcyBpbnRlbmRlZCB0byBiZSBoZWFyZCBieSB0aGUgImZhciIgYnJvd3NlciBhbmQgYW5z d2VyZWQgd2l0aCBtb3JlIFNEUCBmcm9tIHRoZSAiZmFyIiBicm93c2VyLCBhbnkgQVBJIHRoYXQg d2Ugc3BlY2lmeSB3aWxsIGJlIGFraW4gdG8gcG9raW5nIHRoZSBicm93c2VycyB3aXRoIGEgc3Rp Y2sgcmF0aGVyIHRoYW4gZGlyZWN0bHkgZ3JhYmJpbmcgdGhlIGNvbnRyb2xzLiBXaGljaCBpcyBj cmF6eSwgaWYgeW91IHRoaW5rIGFib3V0IGhvdyB0aGUgd2ViIHNlcnZlciArIHRoZSBIVE1MIGFu ZCBKYXZhU2NyaXB0IHRoYXQgaXQgZW1pdHMgaXMgb3RoZXJ3aXNlICpjb21wbGV0ZWx5KiBpbiBj b250cm9sIG9mIHdoYXQgYSBicm93c2VyIGRvZXMuIChTaG9ydCBvZiB0aGUgdXNlciBjbG9zaW5n IHRoZSB3aW5kb3csIGFuZCBldmVuIHRoYXQgY2FuIGJlIGludGVyY2VwdGVkISkNCg0KPiANCj4g DQo+IA0KPiA+IE1heWJlIEknbSB3cm9uZywgYnV0IEknbSBndWVzc2luZyB3aGF0IHlvdSdyZSBz YXlpbmcgd2lsbCBzb3VuZCBsaWtlLg0KPiA+ICAibXkgdXNlIGNhc2UgKGxlZ2FjeSBpbnRlcm9w KSBpcyB0aGUgbW9zdCBpbXBvcnRhbnQgYW5kIG15IHNvbHV0aW9uDQo+ID4gKFNEUCkgaXMgdGhl IGJlc3Qgc29sdXRpb24gZm9yIGV2ZXJ5b25lIGFuZCBJIGtub3cgYmV0dGVyIGJlY2F1c2UgSSd2 ZQ0KPiA+IGJlZW4gd29ya2luZyBvbiBpdCBmb3IgbG9uZ2VyIi4gIEh1YnJpcz8NCj4gDQo+IE5v LCB5b3UndmUgbWlzdW5kZXJzdG9vZCBwcmV0dHkgbXVjaCBldmVyeXRoaW5nIEkgc2FpZC4gSSds bCBzdW1tYXJpemUNCj4gaW4gZmV3ZXIgd29yZHMuDQo+IA0KPiBNeSBwb2ludCBpcyB0aGF0IHdl IG5lZWQgdG8gc29sdmUgdGhlc2UgcHJvYmxlbXMgb25lIHdheSBvciBhbm90aGVyLCBhbmQNCj4g U0RQIGlzbid0IHJlYWxseSB0aGUgcmVhc29uIGl0J3MgZGlmZmljdWx0Lg0KDQpTb21lLCBidXQg bm90IGFsbCwgb2YgdGhlc2UgInByb2JsZW1zIiBuZWVkIHNvbHZpbmcgbm93LiBBIHdob2xlIGxv dCBjYW4gYmUgZGVmZXJyZWQgYW5kIGNlcnRhaW5seSBkb24ndCBuZWVkIGEgdHJpcCB0byBNTVVT SUMgKm5vdyogdG8gc29ydCBvdXQuIEFuIEFQSSB0aGF0IGxldHMgeW91IHNlbmQgYW4gYXVkaW8g YW5kIGEgdmlkZW8gc3RyZWFtIG9uIHRoZSBzYW1lIFJUUCBzZXNzaW9uIGNvdWxkIHNoaXAgKnRv ZGF5Kiwgd2l0aG91dCBhbnkgYWdyZWVtZW50IGFzIHRvIHdoYXQgU0RQIHJlcHJlc2VudHMgdGhh dC4NCg0KPiANCj4gQnV0IGJ5IGluY29ycmVjdGx5IGRlY2lkaW5nIHRoYXQgU0RQIChvciBvZmZl ci9hbnN3ZXIsIGRlcGVuZGluZyBvbiB3aG8NCj4geW91IGxpc3RlbiB0bykgaXMgdGhlIHJlYXNv biBpdCdzIGhhcmQsIHdlJ3JlIHRyeWluZyB0byB0aHJvdyBsZWdhY3kNCj4gaW50ZXJvcCBvdXQg dGhlIHdpbmRvdyBmb3IgdmVyeSBsaXR0bGUgZ2Fpbi4NCg0KTGVnYWN5IGludGVyb3AgaGFzIGJl ZW4gb3V0IHRoZSB3aW5kb3cgZm9yIG92ZXIgYSB5ZWFyIG5vdy4gV2UgaGF2ZSBJQ0UgcmVxdWly ZWQsIHdlIGhhdmUgRFRMUy1TUlRQIHJlcXVpcmVkLCBhbmQgc29ydCBvZiBieSBkZWZpbml0aW9u ICphbnl0aGluZyogdGhhdCBXRUJSVEMgaGFzIGhhZCB0byBnbyB0byBNTVVTSUMgZm9yIG1vcmUg U0RQIHBhcmFtZXRlcnMgZm9yIGlzbid0IGNvbXBhdGlibGUgd2l0aCAibGVnYWN5IiBnZWFyLg0K DQo+IEFuZCwgd2hpbGUgbm90IHRoZSBvbmx5IChvcg0KPiBldmVuIG1haW4pIGNvbnNpZGVyYXRp b24sIGxlZ2FjeSBpbnRlcm9wIGhhcyBzaWduaWZpY2FudCB2YWx1ZS4gSXQgd291bGQNCj4gYmUg YSBzaGFtZSB0byBkZXN0cm95IHRoYXQgdmFsdWUgYmFzZWQgb24gYSBtaXNjb25jZXB0aW9uLg0K DQpUaGUgQVBJIHdlIHByb3Bvc2VkIGNhbiwgYW5kIGFscmVhZHkgaGFzLCBhY2hpZXZlZCBhIGdy ZWF0ZXIgbGV2ZWwgb2YgbGVnYWN5IGludGVyb3AsIHNpbXBseSBieSB0ZWxsaW5nIHRoZSBicm93 c2VyIHdoYXQgdG8gZG8gZnJvbSB0aGUgSmF2YVNjcmlwdCBhcHAsIGFuZCB0aGVuIGluIHRoZSBz YW1lIEphdmFTY3JpcHQgYXBwIGNyZWF0aW5nIGluZm9ybWF0aW9uIHRoYXQgY2FuIGJlIHNlbnQg YnkgdGhlIHNlcnZlciB0byB0aGUgbGVnYWN5IGVxdWlwbWVudCBpbiB3aGF0ZXZlciB3YXkgaXMg Y29tcGF0aWJsZS4gR3JlYXQgdGhpbmcgYWJvdXQgdGhhdCBpcyB0aGF0IHdoZW4gd2UgZmluZCBi dWdzIHdpdGggdGhlIGxlZ2FjeSBnZWFyLCB3ZSBqdXN0IGNoYW5nZSBhIGxpdHRsZSBzZXJ2ZXIg Y29kZSBvciBKYXZhU2NyaXB0IGNvZGUgdGhhdCBnZXRzIHNlbnQgZG93biBmcm9tIHRoZSBzZXJ2 ZXIsLi4uIHJhdGhlciB0aGFuIGhvcGluZyB0aGF0IHNvbWUgZGF5IHRoZSBicm93c2VyIHZlbmRv ciB3aWxsIHNob3cgdXAgd2l0aCBhbiBTRFAgdHdlYWsgdGhhdCBmaXhlcyB0aGUgaXNzdWUuDQoN Cj4gDQo+IFRoZXNlIGlzc3VlcyBhcmVuJ3QgaGFyZCBiZWNhdXNlIG9mIFNEUC4gVGhlc2UgaXNz dWVzIGFyZSBoYXJkIGJlY2F1c2UNCj4gdGhleSdyZSBoYXJkLg0KDQpCdXQgODAlIG9mIHRoZSAi aG93IGRvIEkgcmVwcmVzZW50IHRoaXMgZm9yIG90aGVycyIgZG9lc24ndCBuZWVkIHRvIGJlIHNv bHZlZCBiZWZvcmUgdGhlIHNwZWMgaXMgZmluYWwgd2l0aCBhIHNwZWMgbGlrZSBvdXJzLiBXaGVu IHRoZSBzcGVjIHNheXMgIlNEUCBjb21lcyBvdXQgdGhpcyBob2xlIGhlcmUgYW5kIGdvZXMgaW4g dGhhdCBob2xlIHRoZXJlIiwgaXQgZG9lcy4uLiBhbmQgMTAwJSBkb25lLCB0b28sIG90aGVyd2lz ZSBicm93c2VyIHZlbmRvcnMgYXJlIGdvaW5nIHRvIGJlIGZvcmNlZCB0byBvYmplY3QgdG8gdGhh dCBzcGVjLg0KDQpNYXR0aGV3IEthdWZtYW4NCg0K From bernard_aboba@hotmail.com Fri Jul 19 11:26:59 2013 Return-Path: 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 EAE1A11E8147 for ; Fri, 19 Jul 2013 11:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 KzKnnQRqyKQv for ; Fri, 19 Jul 2013 11:26:54 -0700 (PDT) Received: from blu0-omc3-s24.blu0.hotmail.com (blu0-omc3-s24.blu0.hotmail.com [65.55.116.99]) by ietfa.amsl.com (Postfix) with ESMTP id CA8C221F9DED for ; Fri, 19 Jul 2013 11:26:44 -0700 (PDT) Received: from BLU169-W42 ([65.55.116.73]) by blu0-omc3-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Jul 2013 11:26:41 -0700 X-TMN: [893lJfd4gTpCX2dcoBwfTcD/SBSdBQBW+XmKTabi/fY=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2707f48b-d572-4350-8676-6f4f109abc5a_" From: Bernard Aboba To: Peter Thatcher Date: Fri, 19 Jul 2013 11:26:40 -0700 Importance: Normal In-Reply-To: References: , , , , <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se>, , <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se>, , <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se>, , , , , <51E96B5B.2050302@nostrum.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jul 2013 18:26:41.0620 (UTC) FILETIME=[83D36140:01CE84AD] Cc: "rtcweb@ietf.org" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:27:00 -0000 --_2707f48b-d572-4350-8676-6f4f109abc5a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter Thatcher said:=20 "It's interesting that most of your list of things that needed to be solved= without SDP (simulcast=2C FEC=2C correlation of RTP streams with MediaStre= amTracks=2C glare) still haven't been solved for WebRTC even with SDP=2C de= spite many months (years?) of effort. =0A= =0A= I don't think anyone is saying "without SDP=2C there would be issues". I t= hink they're saying "without SDP=2C the issues are much easier/faster to so= lve=2C and the API would be much more usable and implementable". And I do= n't think that's a naive opinion." [BA] I would even go further - I'd claim that several of these issues are b= est solved without SDP=2C either in the API or on the wire. RTP stacks use= d in WebRTC need to be able to adapt quickly=2C which implies that the adap= tations cannot be signaled. Also=2C if you want to scale=2C then it's impo= rtant to strip out unnecessary operations that create performance bottlenec= ks in media-aware network elements (e.g. decrypt/encrypt operations =2C par= sing of codec-specific parameter sets=2C transcoding=2C etc.). All this poi= nts to moving functionality out of signaling (and codecs) and into RTP. If= you take this perspective=2C then removing SDP dependencies isn't just a b= etter plan for getting to "done" - it's an essential part of delivering the= next generation realtime architecture.=20 = --_2707f48b-d572-4350-8676-6f4f109abc5a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Peter Thatcher said:
=

"It's interesting that most of your list of things that= needed to be solved without SDP (simulcast=2C FEC=2C correlation of RTP st= reams with MediaStreamTracks=2C glare) still haven't been solved for WebRTC= even with SDP=2C despite many months (years?) of effort.  =3B
=0A= =0A=

I don't think anyone is saying "without SDP=2C there wo= uld be issues".  =3BI think they're saying "without SDP=2C the issues a= re much easier/faster to solve=2C and the API would be much more usable and= implementable".  =3B And I don't think that's a naive opinion."
[BA] I would even go further - I'd claim that several of these issues are = best solved without SDP=2C either in the API or on the wire. =3B RTP st= acks used in WebRTC need to be able to adapt quickly=2C which implies that = the adaptations cannot be signaled. =3B Also=2C if you want to scale=2C= then it's important to strip out unnecessary operations that create perfor= mance bottlenecks in media-aware network elements (e.g. decrypt/encrypt ope= rations =2C parsing of codec-specific parameter sets=2C transcoding=2C etc.= ). All this points to moving functionality out of signaling (and codecs) an= d into RTP. =3B If you take this perspective=2C then removing SDP depen= dencies isn't just a better plan for getting to "done" - it's an essential = part of delivering the next generation realtime architecture.


<= /div>
= --_2707f48b-d572-4350-8676-6f4f109abc5a_-- From matthew.kaufman@skype.net Fri Jul 19 11:29:03 2013 Return-Path: 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 B18BD21F9EAF for ; Fri, 19 Jul 2013 11:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.028 X-Spam-Level: X-Spam-Status: No, score=-5.028 tagged_above=-999 required=5 tests=[AWL=1.570, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wyzPySeKxZRJ for ; Fri, 19 Jul 2013 11:28:57 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB6021F9E12 for ; Fri, 19 Jul 2013 11:28:57 -0700 (PDT) Received: from mail67-tx2-R.bigfish.com (10.9.14.229) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 18:28:57 +0000 Received: from mail67-tx2 (localhost [127.0.0.1]) by mail67-tx2-R.bigfish.com (Postfix) with ESMTP id D21373802DB; Fri, 19 Jul 2013 18:28:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85dhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h18c673h1de097hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail67-tx2: 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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail67-tx2 (localhost.localdomain [127.0.0.1]) by mail67-tx2 (MessageSwitch) id 1374258534335554_22599; Fri, 19 Jul 2013 18:28:54 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.226]) by mail67-tx2.bigfish.com (Postfix) with ESMTP id 4CF85360243; Fri, 19 Jul 2013 18:28:54 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 19 Jul 2013 18:28:53 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Fri, 19 Jul 2013 18:27:49 +0000 From: "Matthew Kaufman (SKYPE)" To: Roman Shpount , Adam Roach 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: AQHOhKarH2OEESXTmUGDjlCXp/3ZDplsUWdg Date: Fri, 19 Jul 2013 18:27:48 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97677.1020902@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A48423716F6BTK5EX14MBXC266r_" MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:29:03 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A48423716F6BTK5EX14MBXC266r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 to Roman's comment below. No matter what additional API is produced, as = long as the offer/answer state machine is there and there is SDP going betw= een the browsers the JavaScript is either A) not actually in control of wha= t's happening or B) manipulating a bunch of SDP and running the other side = of that state machine so as to achieve that control. There's another way, we wrote it down and published it almost a year ago, a= nd I still believe that starting with that would get us to a full spec soon= er than the current path... even more so, now that the last 9 months has ac= hieved approximately nothing. Matthew Kaufman From: Roman Shpount [mailto:roman@telurix.com] You cannot be more wrong. Each application deals with predictable set of sc= enarios (ones it produces) and interfaces with predictable set of non webrt= c devices. These external devices are under control of the application deve= loper. Application developer is responsible for interop with these devices.= What is needed is predictable media and signaling generated by webrtc devi= ces running the same application. With negotiation and SDP backed into the = webrtc device it is very hard to achieve. So, for me as webrtc developer le= t me develop a negotiation scheme that works for me and make sure it stay w= orking regardless of the browser type or version. Right now controlling web= rtc application feels like driving the boat down the river by tickling the = captain. _____________ Roman Shpount --_000_AE1A6B5FD507DC4FB3C5166F3A05A48423716F6BTK5EX14MBXC266r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1 to Roman’s comment below. No matter what additional API is = produced, as long as the offer/answer state machine is there and there is SDP going between the browsers the JavaScript is either A) not actually= in control of what’s happening or B) manipulating a bunch of SDP and= running the other side of that state machine so as to achieve that control= .

 <= /p>

There’s another way= , we wrote it down and published it almost a year ago, and I still believe = that starting with that would get us to a full spec sooner than the current path… even more so, now that the last 9 months has achie= ved approximately nothing.

 <= /p>

Matthew Kaufman

 <= /p>

From: Roman Shpount [mailto:roman@telurix.com]

 

You cannot be more wrong. Each application deals wit= h predictable set of scenarios (ones it produces) and interfaces with predi= ctable set of non webrtc devices. These external devices are under control = of the application developer. Application developer is responsible for interop with these devices. What is needed is= predictable media and signaling generated by webrtc devices running the sa= me application. With negotiation and SDP backed into the webrtc device it i= s very hard to achieve. So, for me as webrtc developer let me develop a negotiation scheme that works for = me and make sure it stay working regardless of the browser type or version.= Right now controlling webrtc application feels like driving the boat down = the river by tickling the captain.

_____________
Roman Shpount

 

--_000_AE1A6B5FD507DC4FB3C5166F3A05A48423716F6BTK5EX14MBXC266r_-- From matthew.kaufman@skype.net Fri Jul 19 11:38:38 2013 Return-Path: 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 7292B21E810C for ; Fri, 19 Jul 2013 11:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 zPXQsZbGwC0q for ; Fri, 19 Jul 2013 11:38:32 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id F18A021E80D2 for ; Fri, 19 Jul 2013 11:38:31 -0700 (PDT) Received: from mail196-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 18:38:30 +0000 Received: from mail196-va3 (localhost [127.0.0.1]) by mail196-va3-R.bigfish.com (Postfix) with ESMTP id C3D113A01E4; Fri, 19 Jul 2013 18:38:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zzc89bh1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail196-va3: 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=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail196-va3 (localhost.localdomain [127.0.0.1]) by mail196-va3 (MessageSwitch) id 1374259108813536_16392; Fri, 19 Jul 2013 18:38:28 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.240]) by mail196-va3.bigfish.com (Postfix) with ESMTP id B1A8D300268; Fri, 19 Jul 2013 18:38:28 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 19 Jul 2013 18:38:22 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0136.001; Fri, 19 Jul 2013 18:38:11 +0000 From: "Matthew Kaufman (SKYPE)" To: Adam Roach , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 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: AQHOhJ5X3vuWfZ1FiEyuUoqjlknpnZlsUo3w Date: Fri, 19 Jul 2013 18:38:09 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> In-Reply-To: <51E96B5B.2050302@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: skype.net Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:38:38 -0000 RnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dOg0KPiANCj4gSSB0aGlu ayB0aGlzIGlzIGEgaG9wZWxlc3NseSBuYcOvdmUgaW50ZXJwcmV0YXRpb24gb2YgdGhlIGZhY3Rz IG9uIHRoZSBncm91bmQuDQo+IFNpbXBseSBkaXNjYXJkaW5nIFNEUCBkb2Vzbid0IG1hZ2ljYWxs eSBtYWtlIHRoZSB1bmRlcmx5aW5nIGlzc3VlcyBnbyBhd2F5Lg0KPiBXZSB3b3VsZCBzdGlsbCBu ZWVkIHRvIHNldHRsZSBhIHZhc3QgbnVtYmVyIG9mIGlzc3VlcyBhcm91bmQgdGhpbmdzIGxpa2UN Cj4gc2ltdWxjYXN0LCBGRUMsIGNvZGVjIHBhcmFtZXRlcnMsIGluZGljYXRpb24gb2Ygc3VwcG9y dGVkIGNvZGVjcywgY29ycmVsYXRpb24NCj4gb2YgUlRQIHN0cmVhbXMgd2l0aCBNZWRpYVN0cmVh bVRyYWNrcywgYXR0ZW1wdHMgYnkgYm90aCBwYXJ0aWVzIHRvDQo+IG9wZXJhdGUgb24gdGhlIHNh bWUgc3RyZWFtIHNpbXVsdGFuZW91c2x5IFsxXSwgZXRjLiBCYXNpY2FsbHksIHdpdGggdmVyeSBy YXJlDQo+IGV4Y2VwdGlvbiwgdGhlIHNhbWUgc2V0IG9mIHByb2JsZW1zIHRoYXQgd2UgbmVlZCB0 byBzb2x2ZSBpZiB3ZSAqZG9uJ3QqDQo+IHRocm93IFNEUCBvdXQgdGhlIHdpbmRvdy4NCg0KTm90 IHRvZGF5IHdlIHdvdWxkbid0LiBXZSdkIG5lZWQgYSBoYW5kZnVsIG9uIGtub2JzIHRoYXQgbGV0 IHRoZSBtb3N0IGNvbW1vbiB1c2UgY2FzZXMgYmUgaW1wbGVtZW50ZWQgdW5kZXIgSmF2YVNjcmlw dCBjb250cm9sLCBhbmQgdGhlbiB3ZSBjb3VsZCBsb29rIGF0IHdoYXQgb3RoZXIgQVBJcyBuZWVk IHRvIGJlIGFkZGVkIGxhdGVyLiBOb25lIG9mIHNpbXVsY2FzdCwgRkVELCBvciBhbnkgb2YgdGhv c2UgdGhpbmdzICh3aXRoIHRoZSBleGNlcHRpb24gb2YgdGhlICJhPWZtdCIgc2VjdGlvbiBmb3Ig Y29kZWMgcGFyYW1ldGVycyBvciBhbiBlcXVpdmFsZW50KSBuZWVkcyB0byBiZSBkb25lIHRvIGdl dCBXZWJSVEMgb3V0IHRoZSBkb29yLg0KDQoNCj4gLi4uDQo+IFlvdXIgcGFpbiBwb2ludCBpc24n dCBTRFAgc3ludGF4LiBZZWFoLCBpdCdzIHVnbHksIGJ1dCBpdCdzIG5vdCBoYXJkLg0KPiBZb3Vy IHBhaW4gcG9pbnQgaXNuJ3Qgb2ZmZXIvYW5zd2VyLg0KDQpZZXMgaXQgaXMuIEl0IGltbWVkaWF0 ZWx5IGxpbWl0cyB0aGUgcG9zc2libGUgb3BlcmF0aW9ucyB0aGF0ICphbnkqIEFQSSB3b3VsZCBi ZSBhYmxlIHRvIGFjaGlldmUuDQoNCj4gVHdvIHVuaWxhdGVyYWxseSBkZWNsYXJlZCBzZXNzaW9u cyB0aGF0IGFyZQ0KPiBzaW1wbHkgYmxhc3RlZCBvdXQgb250byB0aGUgd2lyZSBvbmx5IHNhdGlz ZmllcyB0aGUgc2ltcGxlc3Qgb2YgdXNlIGNhc2VzOyB5b3UNCj4gbmVlZCBhIG5lZ290aWF0aW9u LCBhbmQgYW55IGF0dGVtcHQgdG8gZGVmaW5lIGhvdyB0aGF0IG5lZ290aWF0aW9uIGxvb2tzIGlz DQo+IGdvaW5nIHRvIGFycml2ZSBhdCBzb21ldGhpbmcgd2l0aCBlbm91Z2ggcnVsZXMgdGhhdCBp dCBpcyBzdWJzdGFudGlhbGx5IGFzDQo+IGNvbXBsaWNhdGVkIGFzIG9mZmVyL2Fuc3dlci4NCg0K U2ltcGx5IG5vdCB0cnVlLiBPZmZlci9hbnN3ZXIgaXMgb25seSBvbmUgd2F5IHRvIGdldCB0d28g dGhpbmdzIHRvIHRhbGsgdG8gZWFjaCBvdGhlciwgYW5kIGl0IGlzIGEgInRydW5rIHNpZGUiICJw ZWVyIHRvIHBlZXIiIG5lZ290aWF0aW9uIHRoYXQgYXNzdW1lcyBubyBpbnRlbGxpZ2VuY2UgaW4g dGhlIG1pZGRsZS4NCg0KPiANCj4gTm8sIHlvdXIgcGFpbiBwb2ludCBoZXJlIGlzIHRoYXQgbm9u LW1hc3Rlci1zbGF2ZSBuZXR3b3JrZWQNCj4gY29tbXVuaWNhdGlvbnMgYXJlIG5vdCBlYXN5IHRv IGdldCByaWdodA0KDQpBaGEhIEkgdGhpbmsgSSBzZWUgeW91ciBwcm9ibGVtIGhlcmUuDQoNCklm IHdlIGdpdmUgdGhlIHdlYiBkZXZlbG9wZXIgc29tZSBKYXZhU2NyaXB0IEFQSXMsIHRoZW4gaXQg aXNuJ3QgIm5vbi1tYXNlci1zbGF2ZSBuZXR3b3JrZWQgY29tbXVuaWNhdGlvbnMiLiBJbiBmYWN0 IGl0IGlzIGV4YWN0bHkgdGhlIG9wcG9zaXRlLiANCg0KSnVzdCBsaWtlIGFsbCBvdGhlciAiSFRN TDUiIHRlY2hub2xvZ2llcyB3ZSBzaG91bGQgYmUgYXNzdW1pbmcgdGhhdCB0aGUgd2ViIHNlcnZl ciBhbmQgdGhlIEhUTUwrSlMgaXQgc2VuZHMgZG93biAqaXMgdGhlIG1hc3RlciosIHRlbGxpbmcg dGhlIGJyb3dzZXIgZXhhY3RseSB3aGF0IGl0IHNob3VsZCBkby4gSW4gdGhpcyBzY2VuYXJpbywg dGhlcmUgYXJlIGEgbXVsdGl0dWRlIG9mIHdheXMsIGZyb20gc2ltcGxlIHRvIGNvbXBsZXgsIHRv IGVuc3VyaW5nIHRoYXQgYm90aCAob3IgbW9yZSwgZm9yIGFueSBub24gMS0xIHVzZSBjYXNlKSBl bmRzIGFyZSBzZW5kaW5nIGRhdGEgb3ZlciB0aGVpciBuZXR3b3JrIGNvbm5lY3Rpb24gdGhhdCB0 aGUgb3RoZXIgZW5kIGNhbiB1c2UgYW5kIHJlbmRlci4NCg0KPiBJIHVuZGVyc3RhbmQgY29tbWVu dCAyMiBhdCBpdHMgY29yZSBbMl0sIGJ1dCBpdCBoYXMgYSBjb3JvbGxhcnk6IGFueSBzeXN0ZW0N Cj4gdGhhdCByZXBsYWNlcyBTRFAgTy9BIHdpbGwgZW5kIHVwIGJlaW5nIHNpbWlsYXIgaW4gY29t cGxleGl0eSBvbmNlIGFsbA0KPiBpbnRlcmVzdGVkIHBhcnRpZXMnIHVzZSBjYXNlcyBoYXZlIGJl ZW4gZmFjdG9yZWQgaW4uDQoNCkkgZG91YnQgaXQuIEJ1dCBldmVuIGlmIHRoYXQncyB0cnVlLCBp dCB3aWxsIGdpdmUgdGhlIEphdmFTY3JpcHQgZGV2ZWxvcGVyIGRpcmVjdCBjb250cm9sIG92ZXIg d2hhdCBpcyBoYXBwZW5pbmcsIGFuZCB0aGF0J3MgYSB3aW4uIEFuZCBsaWtlbHksIG11Y2ggb2Yg dGhlICJleHRyYSBjb21wbGV4aXR5IiB5b3UgYXJlIHRoaW5raW5nIG9mIHdpbGwgZW5kIHVwIGlu IHNoYXJlZCBKUyBsaWJyYXJpZXMsIG5vdCBiYWtlZCBpbnRvIGEgYnJvd3Nlci4gQW5kIHRoZSBs ZWdhY3kgaW50ZXJvcCB5b3UncmUgY29uY2VybmVkIGFib3V0PyBBbnkgY29tcGF0aWJpbGl0eSBp c3N1ZXMgd2lsbCBnZXQgZml4ZWQgcmlnaHQgaW4gdGhhdCBzYW1lIHBsYWNlLCBsb25nIGJlZm9y ZSBhbnkgYnJvd3NlciB2ZW5kb3Igd29ya3Mgb3V0IGV4YWN0bHkgd2hhdCBpcyBuZWNlc3Nhcnkg dG8gd29yayB3aXRoIGEgcGFydGljdWxhciBkZXZpY2UgdGhhdCBhIHdlYiBzaXRlIG9wZXJhdG9y IGNhcmVzIGZvciB0aGVpciB1c2VycyB0byBjb25uZWN0IHRvLg0KDQpNYXR0aGV3IEthdWZtYW4N Cg0KcHMuIENvbW1lbnQgMjIgaXNuJ3QgIlNEUCBpcyBoYXJkIi4uLiByYXRoZXIgaXQgaXMgImlm IHlvdSB3ZXJlIHVzaW5nIG91ciBBUEksIHlvdSB3b3VsZG4ndCBiZSBlbmNvdW50ZXJpbmcgdGhp cyBpc3N1ZSBhdCBhbGwiDQo= From matthew.kaufman@skype.net Fri Jul 19 11:40:57 2013 Return-Path: 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 26F6311E8197 for ; Fri, 19 Jul 2013 11:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 wW+dKZMHTuex for ; Fri, 19 Jul 2013 11:40:50 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 779CC11E8180 for ; Fri, 19 Jul 2013 11:40:50 -0700 (PDT) Received: from mail69-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE019.bigfish.com (10.3.207.141) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 18:40:49 +0000 Received: from mail69-am1 (localhost [127.0.0.1]) by mail69-am1-R.bigfish.com (Postfix) with ESMTP id 197FD4E0139; Fri, 19 Jul 2013 18:40:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zzda00h1432Idc73hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail69-am1: 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=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail69-am1 (localhost.localdomain [127.0.0.1]) by mail69-am1 (MessageSwitch) id 137425924791385_26168; Fri, 19 Jul 2013 18:40:47 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.250]) by mail69-am1.bigfish.com (Postfix) with ESMTP id 12AE3480046; Fri, 19 Jul 2013 18:40:47 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 19 Jul 2013 18:40:46 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Fri, 19 Jul 2013 18:40:40 +0000 From: "Matthew Kaufman (SKYPE)" To: Martin Thomson , Adam Roach 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+XES8EqmiU0dHnZlsVW5g Date: Fri, 19 Jul 2013 18:40:38 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:40:57 -0000 RnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dDQo+ IA0KPiBOZWdvdGlhdGlvbiBpcyBhIGhvbGUuICBBIHZhc3QsIHNvdWwtc3Vja2luZywgd2FzdGUg b2YgdGltZS4NCg0KQW5kIG5lZ290aWF0aW9uIG92ZXIgU0RQIHJlcXVpcmVzIGEgdHJpcCB0byBN TVVTSUMgZXZlcnkgdGltZSB5b3UgdGhpbmsgb2Ygc29tZXRoaW5nIG5ldywgdG9vLiBUaGF0J3Mg YSBzb3VsLXN1Y2tpbmcgd2FzdGUgb2YgdGltZSAqaXRzZWxmKi4NCg0KTWF0dGhldyBLYXVmbWFu DQo= From matthew.kaufman@skype.net Fri Jul 19 11:42:32 2013 Return-Path: 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 5796911E8180 for ; Fri, 19 Jul 2013 11:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, HTML_MESSAGE=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 R40dNkZ-oyLw for ; Fri, 19 Jul 2013 11:42:26 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 65F3E11E819F for ; Fri, 19 Jul 2013 11:42:25 -0700 (PDT) Received: from mail41-db9-R.bigfish.com (10.174.16.246) by DB9EHSOBE001.bigfish.com (10.174.14.64) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 18:42:24 +0000 Received: from mail41-db9 (localhost [127.0.0.1]) by mail41-db9-R.bigfish.com (Postfix) with ESMTP id 62485C00109; Fri, 19 Jul 2013 18:42:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz98dI9371Ic89bhc85dhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL18c673h1de097h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail41-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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail41-db9 (localhost.localdomain [127.0.0.1]) by mail41-db9 (MessageSwitch) id 1374259342286396_29934; Fri, 19 Jul 2013 18:42:22 +0000 (UTC) Received: from DB9EHSMHS010.bigfish.com (unknown [10.174.16.225]) by mail41-db9.bigfish.com (Postfix) with ESMTP id 3E3B5C40049; Fri, 19 Jul 2013 18:42:22 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS010.bigfish.com (10.174.14.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 19 Jul 2013 18:42:18 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Fri, 19 Jul 2013 18:42:13 +0000 From: "Matthew Kaufman (SKYPE)" To: Ted Hardie , Martin Thomson 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+XES8EqmiU0dHnZlsO5AAgAAaLNA= Date: Fri, 19 Jul 2013 18:42:12 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A484237170CATK5EX14MBXC266r_" 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" , "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:42:32 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A484237170CATK5EX14MBXC266r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So we should have APIs that let JavaScript applications adapt to these diff= erent environments (like we do for everything else in "HTML5"), *not* try t= o solve this by making the API be "tickling the ship captain" and attemptin= g to do everything else in a pairwise negotiation between two elements, one= of which might not even be a browser. Matthew Kaufman From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: Friday, July 19, 2013 10:07 AM To: Martin Thomson Cc: Adam Roach; I=F1aki Baz Castillo; Cullen Jennings; Matthew Kaufman (SKY= PE); ; public-webrtc@w3.org Subject: Re: On babies and bathwater (was Re: [rtcweb] Summary of Applicati= on Developers' opinions of the current WebRTC API and SDP as a control surf= ace) On Fri, Jul 19, 2013 at 9:54 AM, Martin Thomson > wrote: Negotiation is a hole. A vast, soul-sucking, waste of time. Even if you have the same javascript application downloaded, you will have = disparate capabilities in the environments into which it is downloaded (bro= wser/os/codecs/media sources/available network capacity). Getting set inte= rsection and preference order for those capabilities is something that appl= ications actually want. You may be able to move the pain of that around, b= ut it isn't a waste of time. My personal opinion, with no IETF hats or company swag, Ted --_000_AE1A6B5FD507DC4FB3C5166F3A05A484237170CATK5EX14MBXC266r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

So we should have APIs that let JavaScript applications adapt to these d= ifferent environments (like we do for everything else in “HTML5”= ;), *not* try to solve this by making the API be “tickling the sh= ip captain” and attempting to do everything else in a pairwise negoti= ation between two elements, one of which might not even be a browser.<= /o:p>

 <= /p>

Matthew Kaufman

 <= /p>

From: Ted Ha= rdie [mailto:ted.ietf@gmail.com]
Sent: Friday, July 19, 2013 10:07 AM
To: Martin Thomson
Cc: Adam Roach; I=F1aki Baz Castillo; Cullen Jennings; Matthew Kaufm= an (SKYPE); <rtcweb@ietf.org>; public-webrtc@w3.org
Subject: Re: On babies and bathwater (was Re: [rtcweb] Summary of Ap= plication Developers' opinions of the current WebRTC API and SDP as a contr= ol surface)

 

On Fri, Jul 19, 2013 at 9:54 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:


Negotiation is a hole.  A vast, soul-sucking, waste of time.


Even if you have the same javascript application downloaded, you will have = disparate capabilities in the environments into which it is downloaded (bro= wser/os/codecs/media sources/available network capacity).  Getting set= intersection and preference order for those capabilities is something that applications actually want.  You= may be able to move the pain of that around, but it isn't a waste of time.=

My personal opinion, with no IETF hats or company swag,

Ted

--_000_AE1A6B5FD507DC4FB3C5166F3A05A484237170CATK5EX14MBXC266r_-- From pthatcher@google.com Fri Jul 19 11:47:53 2013 Return-Path: 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 8164511E8145 for ; Fri, 19 Jul 2013 11:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.253, 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 sl3vPagdgJVe for ; Fri, 19 Jul 2013 11:47:52 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49A11E818D for ; Fri, 19 Jul 2013 11:47:52 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so4597712pdi.27 for ; Fri, 19 Jul 2013 11:47:52 -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=SAaka8Xu0QikonOGz5I3gNumRSvSYX1iAhkUcBM0LF8=; b=I/k0uan9An2SsMVf2pN8AwIJaieSNQXurUxlZGqGLDnkivHHK29kGpMJpyMuhNM+lF T/CNg1rmB8C/XJtCQqcanrLtuTK12Mc1L2l1Itn8PdTu8hvgag0b/wL5vLXAUE7G948F /H4MlklFz0EKwLqXIneukSmAcapLIexsnfAKv8WNNQ1y0RVLOcStmafaZ7ZdtIdhDPaS wHQ5qxNm4lLwYVPW71QPF5Z55p1SX0TE4ZFwt9yWXVI2gFbMKCWb8nKi3upalWdVqPh5 IV9iBNzNsuqcrHNdHxeP6xfkWTykuOAHe2BrvYO5bGBHjGtBOWagL7X0Hs6/qiXFvBPr T3pg== 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=SAaka8Xu0QikonOGz5I3gNumRSvSYX1iAhkUcBM0LF8=; b=d9SNlBrTf6dsp92GmZQdlTgJ6QV8EhaEwA94328c/bVfb5Iuhw5yV4VXtDDPE7zAYF 1VcWaUk0YhpXlmKF3zQn7QAOWNuhsKnnOstD3QXNn2BYJ43IPrLWdPCaJovsMZ9zaFAF 3U64ZPyBgM/hme/obL3Ls9p5r4d4g5afLJ4Md0PZ4spUKaIGJ6DwC+uzhOuq4E46OCkY aCB5j5BRinn6vMSjrrbrZkW02HCTpTHhqZZVVijQzgx5c+FAJWVZpdaukFh6XUJ80zwX 4cWnrL847DvqOOATjUQgORVr+S3hPrJ2668UUYaG2VdMPEQmlNC1GsK/iKslbAD/2WmF 88Xw== X-Received: by 10.68.104.196 with SMTP id gg4mr18930858pbb.25.1374259672063; Fri, 19 Jul 2013 11:47:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 11:47:10 -0700 (PDT) In-Reply-To: <51E97C41.5050208@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97C41.5050208@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 11:47:10 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=047d7b6705b9953e7d04e1e1c354 X-Gm-Message-State: ALoCoQkLATVQze8Z1voUjn6f8I2Oi9urEsU72NCAk99nzV5EJ1W0ykqmMt6wVhtGP6CmvPsv22q/PTvB+4/n6qoecRjaAak2LFpCGyqvE+LlallXG/QwbgNW6oBAUVlQpuJsZkb9aqszxJVzFfK2mQer34kUY2SfuHykIWvou3kZr5oT8tWMBRwyMRqk0Dia9/Ozh+8JEuwf Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:47:53 -0000 --047d7b6705b9953e7d04e1e1c354 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 10:49 AM, Adam Roach wrote: > On 7/19/13 12:18, Peter Thatcher wrote: > >> Please try to consider what you sound like to a web developer who is >> trying to use WebRTC and finding SDP to be difficult API surface. >> > > I think any time someone says they've used the SDP directly as a control > surface in a JavaScript application, it indicates a hole in the current > WebRTC specification that we need to fix. > > SDP is not supposed to be the WebRTC API surface. > > I think we all pretty much agree that SDP is not supposed to be the WebRTC > API surface. > > I think we're pretty much all on the same page that we need to add stuff > to the current API to handle these use cases. If SDP isn't the control surface, than what is the API surface? The only way to tell the browser to setup an ICE connection is to give it SDP. The only way to tell it to send and receive RTP packets is to give it SDP. The browser might produce the SDP for you, and you might be told not to change it, but at the end of the day, the commands that make the browser setup ICE connections and send and receive RTP is the SDP. Therefore, SDP is the API control surface. Until JS can setup an ICE connection and send and receive RTP packets without giving the browser SDP, then SDP is the control surface. This might not be so bad for applications that use SDP for signalling, but any app that uses something other than SDP for signalling necessarily views SDP as the API surface, since there is no other way to tell the browser what to do. > > > > Maybe I'm wrong, but I'm guessing what you're saying will sound like. >> "my use case (legacy interop) is the most important and my solution (SDP) >> is the best solution for everyone and I know better because I've been >> working on it for longer". Hubris? >> > > No, you've misunderstood pretty much everything I said. I'll summarize in > fewer words. > > You called everyone who doubts the SDP API naive and full of hubris, and now you're telling me I'm misunderstanding pretty much everything. > My point is that we need to solve these problems one way or another, and > SDP isn't really the reason it's difficult. > One problem is that this is a very difficult to use API for web developers. And SDP is at the heart of that problem. Lots of people have said so, and why, in great detail. Do you really believe all of them are naive and full of hubris? > > But by incorrectly deciding that SDP (or offer/answer, depending on who > you listen to) is the reason it's hard, we're trying to throw legacy > interop out the window for very little gain. I think this is the real issue at hand: You value legacy interop more than a usable API. Other value a usable API more than legacy interop. You're willing to sacrifice API usability for legacy interop, and they're willing to sacrifice legacy interop for a usable API. There are different groups with different needs and different perspectives. I think we can have both legacy interop and a usable API, and there are many ways we can achieve that. But we've been asked to delay talking about it until "1.0" is done. So, we'll have to wait for further discussion. > And, while not the only (or even main) consideration, legacy interop has > significant value. It would be a shame to destroy that value based on a > misconception. > > These issues aren't hard because of SDP. These issues are hard because > they're hard. SDP as an API surface makes the API worse. And API surface that didn't require SDP would be a better API surface. It's a fallacy to assume that because we need legacy interop, we have to support it to the detriment of of non-legacy interop use cases. We could have both, if we wanted to design an API for both. Please try to realize that there are worlds of use cases beyond yours, and there are lots of people with different needs than yours. And please try to listen to them rather than just calling them naive and full of hubris. > > > /a > --047d7b6705b9953e7d04e1e1c354 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 10:49 AM, Adam Roach <= adam@nostrum.com&= gt; wrote:
On 7/19/13 12:18, Peter Thatcher wrote:<= br>
Please try to consider what you sound like to a web developer who is trying= to use WebRTC and finding SDP to be difficult API surface.

I think any time someone says they've used the SDP directly as a contro= l surface in a JavaScript application, it indicates a hole in the current W= ebRTC specification that we need to fix.

SDP is not supposed to be the WebRTC API surface.

I think we all pretty much agree that SDP is not supposed to be the WebRTC = API surface.

I think we're pretty much all on the same page that we need to add stuf= f to the current API to handle these use cases.

=
If SDP isn't the control surface, than what is the API surface? = =C2=A0The only way to tell the browser to setup an ICE connection is to giv= e it SDP. =C2=A0The only way to tell it to send and receive RTP packets is = to give it SDP. =C2=A0The browser might produce the SDP for you, and you mi= ght be told not to change it, but at the end of the day, the commands that = make the browser setup ICE connections and send and receive RTP is the SDP.= =C2=A0 Therefore, SDP is the API control surface. =C2=A0Until JS can setup= an ICE connection and send and receive RTP packets without giving the brow= ser SDP, then SDP is the control surface. =C2=A0

This might not be so bad for applications that use SDP = for signalling, but any app that uses something other than SDP for signalli= ng necessarily views SDP as the API surface, since there is no other way to= tell the browser what to do.








Maybe I'm wrong, but I'm guessing what you're saying will sound= like. =C2=A0"my use case (legacy interop) is the most important and m= y solution (SDP) is the best solution for everyone and I know better becaus= e I've been working on it for longer". =C2=A0Hubris?

No, you've misunderstood pretty much everything I said. I'll summar= ize in fewer words.


You called everyone who doubts the SDP= API naive and full of hubris, and now you're telling me I'm misund= erstanding pretty much everything.
=C2=A0
My point is that we need to solve these problems one way or another, and SD= P isn't really the reason it's difficult.

=
One problem is that this is a very difficult to use API for web = developers. =C2=A0And SDP is at the heart of that problem. =C2=A0Lots of pe= ople have said so, and why, in great detail. =C2=A0Do you really believe al= l of them are naive and full of hubris?
=C2=A0

But by incorrectly deciding that SDP (or offer/answer, depending on who you= listen to) is the reason it's hard, we're trying to throw legacy i= nterop out the window for very little gain.

I think this is the real issue at hand: =C2=A0You value legacy interop= more than a usable API. =C2=A0Other value a usable API more than legacy in= terop. =C2=A0You're willing to sacrifice API usability for legacy inter= op, and they're willing to sacrifice legacy interop for a usable API. = =C2=A0There are different groups with different needs and different perspec= tives. =C2=A0

I think we can have both legacy interop and a usable AP= I, and there are many ways we can achieve that. =C2=A0But we've been as= ked to delay talking about it until "1.0" is done. =C2=A0So, we&#= 39;ll have to wait for further discussion. =C2=A0


=C2=A0
And, while= not the only (or even main) consideration, legacy interop has significant = value. It would be a shame to destroy that value based on a misconception.<= br>
These issues aren't hard because of S= DP. These issues are hard because they're hard.

SDP as an API surface makes the API worse. =C2=A0And AP= I surface that didn't require SDP would be a better API surface. =C2=A0= It's a fallacy to assume that because we need legacy interop, we have t= o support it to the detriment of of non-legacy interop use cases. =C2=A0We = could have both, if we wanted to design an API for both.

Please try to realize that there are worlds of use case= s beyond yours, and there are lots of people with different needs than your= s. =C2=A0And please try to listen to them rather than just calling them nai= ve and full of hubris.
=C2=A0


/a

--047d7b6705b9953e7d04e1e1c354-- From adam@nostrum.com Fri Jul 19 11:51:47 2013 Return-Path: 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 7B2DE11E8190 for ; Fri, 19 Jul 2013 11:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 1xrR7S4aIcIJ for ; Fri, 19 Jul 2013 11:51:47 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7458311E8193 for ; Fri, 19 Jul 2013 11:51:46 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JIpcOZ084138 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 13:51:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E98AB5.3090209@nostrum.com> Date: Fri, 19 Jul 2013 13:51:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Thatcher References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97C41.5050208@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:51:47 -0000 On 7/19/13 13:47, Peter Thatcher wrote: > Do you really believe all of them are naive and full of hubris? No, I think they're using an API that is nowhere near finished yet, which is necessarily going to be painful. The complaints are legitimate. The scapegoating of SDP is what's misguided. /a From pthatcher@google.com Fri Jul 19 11:57:35 2013 Return-Path: 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 93F6E21F8319 for ; Fri, 19 Jul 2013 11:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.246, 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 68uEMkC6K7Kz for ; Fri, 19 Jul 2013 11:57:35 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8648121F9A4A for ; Fri, 19 Jul 2013 11:57:28 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so4741826pbb.19 for ; Fri, 19 Jul 2013 11:57:28 -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=f0OVokcGGihE/YrgB4jA1+4u9trAYudAeX9lYkLvu5I=; b=hK8MfQCVF7stlXNZtrlcfXUFHSvQDBOpGSeGZPvz0wSj3tOww0wNxw4uWf2nTEWjtF o4zF+vz5tk6kv7+NNHgGzvEpL4f8+IVSCFI9LsqV8FW3jZf7AzT3e1nFycXdOdwGddAZ dygVcHGgOvQxQj4qUQ1r/BgdRO85MSC6Kh+2lFqXF6l+j/V1ENWxrHh33J3fv2Mqz8p7 LTw7MURsp48msPg3uy2atbeURzqSwwY76KrYIvvc7vqoQ+1a64VETwwYm9EpX2cAueDe OSGudEHpK9bh5q/QXu10lH2BiVSYTYxsqD7xpm2UxXOxetb2JK4oYYOe27ZIJpd9i+W8 NYIg== 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=f0OVokcGGihE/YrgB4jA1+4u9trAYudAeX9lYkLvu5I=; b=a/RLSwDQHjXsubR0OPV/Li4/tA5eVdztQe0jez4d3X3oRTVbbYGwYKAXJF6sxvizn5 fyzivDMu80BerbY9400zzVFVuqh2tOzUBdfD7wq+683ydgaSBEMRyh2wHPK2m26jSA9k MIiMhvYvtp76ekKRKzwf86NlV0DY+XhhXQ8KPNxz3cr0F+XRBk0AZWx4fKYq7lwhy7YH zMswKOl3IKrwUwfA+xdNaw9SFUFs2rsp5g1vIbAWlQNChd80DuSHde/WCKsk2T8TCin3 0HXqoOpy8SH/b/EZq59gTe3SFlVDNWjuPqFOa84UxQTs7kIC3VEgjsLhawCymzOJgnk2 X59g== X-Received: by 10.68.219.130 with SMTP id po2mr18590442pbc.54.1374260248234; Fri, 19 Jul 2013 11:57:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 11:56:48 -0700 (PDT) In-Reply-To: <51E97C86.2090808@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E978C2.8000002@nostrum.com> <51E97C86.2090808@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 11:56:48 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=e89a8ff24881eceb3804e1e1e532 X-Gm-Message-State: ALoCoQn5O2h2x2kwPo5LS89PdBkUp+fMtWZ6TH6LYMIDtHZpMt70RxY/mCx/5LguZUSWd08XWTACrTXN6hkzB7nfk2RxCtkkBuGvYtr20K9aD68PNTtQ5mwRaPcgDzye0x1nraXjKqlPXH3BK+2JQGX+NO/ml9gh83yoKGdQS1Q+NbjyXmfbwbeF+7WOrXYG4l9DYMIqzdQB Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:57:35 -0000 --e89a8ff24881eceb3804e1e1e532 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 10:51 AM, Adam Roach wrote: > On 7/19/13 12:39, Peter Thatcher wrote: > >> >> So, are you trying to say "Look how hard this is to do with SDP. We're >> not even done yet. It will be even harder without SDP"? >> >> > No. I'm not saying it would be harder. I'm saying it wouldn't be easier, It wouldn't be harder, and it wouldn't be easier. So, it would be about the same amount of work for either? > and you would lose tangible benefits. I still don't understand how this could be true. If we define an API that allows JS to use either SDP or not, at its choice, how is that a loss? It seems like only a gain. > /a > --e89a8ff24881eceb3804e1e1e532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 10:51 AM, Adam Roach <= adam@nostrum.com&= gt; wrote:
On 7/19/13 12:39, Peter Thatcher wrote:

So, are you trying to say "Look how hard this is to do with SDP. =C2= =A0We're not even done yet. =C2=A0It will be even harder without SDP&qu= ot;?


No. I'm not saying it would be harder. I'm saying it wouldn't b= e easier,


It wouldn't be harde= r, and it wouldn't be easier. =C2=A0So, it would be about the same amou= nt of work for either?=C2=A0

=C2=A0
and you would lose = tangible benefits.

I still don't understand how this could be true. = =C2=A0If we define an API that allows JS to use either SDP or not, at its c= hoice, how is that a loss? =C2=A0It seems like only a gain.

<= /div>

=C2=A0

=C2=A0
/a

--e89a8ff24881eceb3804e1e1e532-- From matthew.kaufman@skype.net Fri Jul 19 11:59:54 2013 Return-Path: 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 B738921F84D9 for ; Fri, 19 Jul 2013 11:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.088 X-Spam-Level: X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[AWL=-0.489, 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 pyHz2+m0MJnP for ; Fri, 19 Jul 2013 11:59:48 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB6511E8179 for ; Fri, 19 Jul 2013 11:59:43 -0700 (PDT) Received: from mail203-db9-R.bigfish.com (10.174.16.238) by DB9EHSOBE026.bigfish.com (10.174.14.89) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 18:59:31 +0000 Received: from mail203-db9 (localhost [127.0.0.1]) by mail203-db9-R.bigfish.com (Postfix) with ESMTP id 4DC8240162; Fri, 19 Jul 2013 18:59:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail203-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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail203-db9 (localhost.localdomain [127.0.0.1]) by mail203-db9 (MessageSwitch) id 1374260369317884_13225; Fri, 19 Jul 2013 18:59:29 +0000 (UTC) Received: from DB9EHSMHS028.bigfish.com (unknown [10.174.16.236]) by mail203-db9.bigfish.com (Postfix) with ESMTP id 3F7CA2C0044; Fri, 19 Jul 2013 18:59:29 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS028.bigfish.com (10.174.14.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 19 Jul 2013 18:59:28 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Fri, 19 Jul 2013 18:59:23 +0000 From: "Matthew Kaufman (SKYPE)" To: Adam Roach , Peter Thatcher 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: AQHOhKQOxbdxSe2FO0i0LZeMXs0KIJlsR3aAgAAQAQCAAAE6gIAAAIPg Date: Fri, 19 Jul 2013 18:59:22 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97C41.5050208@nostrum.com> <51E98AB5.3090209@nostrum.com> In-Reply-To: <51E98AB5.3090209@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:59:54 -0000 RnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dOg0KPg0KPiBObywgSSB0 aGluayB0aGV5J3JlIHVzaW5nIGFuIEFQSSB0aGF0IGlzIG5vd2hlcmUgbmVhciBmaW5pc2hlZCB5 ZXQsIHdoaWNoIGlzDQo+IG5lY2Vzc2FyaWx5IGdvaW5nIHRvIGJlIHBhaW5mdWwuIFRoZSBjb21w bGFpbnRzIGFyZSBsZWdpdGltYXRlLg0KPiANCj4gVGhlIHNjYXBlZ29hdGluZyBvZiBTRFAgaXMg d2hhdCdzIG1pc2d1aWRlZC4NCg0KSSBjb3VsZCBhY3R1YWxseSBsaXZlIHdpdGggU0RQLCB0aG91 Z2ggaXQgaXMgcHJldHR5IGNsdW5reS4gV2hhdCBJIGNhbid0IGxpdmUgd2l0aCBpcyBoYXZpbmcg YW4gb2ZmZXIvYW5zd2VyIHN0YXRlIG1hY2hpbmUgaW4gdGhlIGJyb3dzZXIuIEFuZCBJIGhhdmUg ZW5vdWdoIGV4cGVyaWVuY2Ugd2l0aCBzdWNoIHRoaW5ncyB0aGF0IEkgdGhpbmsgdGhlcmUncyBh IGJldHRlciB3b3JkIHRoYW4gIm1pc2d1aWRlZCIgdG8gZGVzY3JpYmUgbXkgZmVlbGluZ3MuDQoN Ck1hdHRoZXcgS2F1Zm1hbg0K From pthatcher@google.com Fri Jul 19 12:05:16 2013 Return-Path: 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 DF9F421E805D for ; Fri, 19 Jul 2013 12:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.239, 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 WLMCu8pMzqES for ; Fri, 19 Jul 2013 12:05:16 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 43CDF11E8197 for ; Fri, 19 Jul 2013 12:05:16 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl14so4710394pab.20 for ; Fri, 19 Jul 2013 12:05:15 -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=aqSkGOi+qRo/32iyl2/KirT/YOM1NURUsD1lmlhuSOQ=; b=RhXTaqVmUeR0sdnD2coWUBcZAGRybqdmH51Ek1aBzlUo/5HHvFY5ZE3WrhW2BMshLc MJzHD2ansd5CMu4ykgw+oBe3xzGv/KTcEbOtjmZMZ2BWbWuPEyeZrqjU7sJ4zoDco0kc OkODa567WKNHMQlnDbmMiepXgB/wTORZ9zQCpqcFKUoEzyRBIzbTOfZ5awgqqYtL4HL6 bhH55l5PF9PnK9+9nTV8+l/pFYoLhjVu1+1AKAKbpRnFTTClS3xq77acPlGS3l98Eb6a gCkAWN8HN5rFM6mjMP7IFerrN0hX0RSQ+Y/TtJPnZmzz2dlogmuGmTYSuH8MaeVHsMTD 1lHg== 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=aqSkGOi+qRo/32iyl2/KirT/YOM1NURUsD1lmlhuSOQ=; b=M8Jk1XQCBsQhk0nfNM4Q1gfTs3HFDTrcBG+Pwnnq4+8kxdyC+8u9ORvFJteQnC3xdu y+jFgXJ//wvO6feVIeI052FNHvxvrJWeJXlr9DPWI5NHFA/frtXV4QGBrg1p3FYo6xZ0 TByZhUB5SnD/E/t/4tucPrp9JuC1T5pfxqscLU2TlSTRfPH35UIh2ehq7NuGs3c7XRl0 RvKxc3Gm9cJ9UhwVrvk/C0BxCevBqwo5kftDFt2wepYgXztrS23AfWiBCltMGYwRtI7J tOuWBzfggRCsKHwWkPErn/CRE84bubDaEMz+buHOxZ1OoLEPzVem8GqN9XU+6dzL43AK LVKQ== X-Received: by 10.66.141.4 with SMTP id rk4mr19477557pab.127.1374260715731; Fri, 19 Jul 2013 12:05:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 12:04:35 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E978C2.8000002@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 12:04:35 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c39d18ca604604e1e20115 X-Gm-Message-State: ALoCoQnFYXqJPofMmRnfI5lGFJ7T6/sgP9BgNuYWtei6m8Y/eCdpLBuUblsTSqF9qXMAFCtkpU/hGkPJbQexlDlsLHPY54O5xoDa7tqA8D0trVExH71PHUIPtrk14DcD9VrcMzxUpK1FHSvRqq6CG2mUJQgX8vvp8wTZX7urILssU745ZAZv/mWkagRA9912XdE1cOtKJq17 Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:05:17 -0000 --001a11c39d18ca604604e1e20115 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 10:57 AM, Martin Thomson wrote: > On 19 July 2013 10:39, Peter Thatcher wrote: > > So, are you trying to say "Look how hard this is to do with SDP. We're > not > > even done yet. It will be even harder without SDP"? > > In the Atlanta meeting (Nov 2012) I remember waiting for those damned > elevators with Justin. He said something like: "So, if we'd chosen > comment 22 [CU-RTC-Web] do you think we'd be done by now?" I was > quick to answer, "Of course not." After all, we'd only made that > proposal 3-4 months earlier. I know that nothing gets done in less > than a year, and this is not a small undertaking. > > Since then, I've gained a more nuanced view. We've set an impossibly > high bar for this specification, including all sorts of crazy > features: FEC, simulcast, layered codecs, congestion control, > undeployed codecs, multiplexing, and not to mention a new data > channel. > > In reality, SDP never negotiated all that crap before. Worse, despite > the existence of RFCs for most of these features, it turns out that > most implementations were proprietary. We couldn't even agree on what > an m-line represents. > > So, if asked the same question today, I'd probably have to say: "We'd > at least have had basic scenarios shipped. We might not have sorted > out the hard cases like layered codecs, but we do have basic > functionality." > > What we have this the complete antithesis of any project I've been > involved in over the past 10 years. It's gold-plating the pink > squirrel. > > If we want to ship this thing, then we should be managing scope, not > protecting it. > Slight aside, but is this a correct model of what has happened with regards to scope? The W3C is waiting for the IETF RTCWEB WG. The RTCWEB WG is waiting for the MMUSIC WG. The MMUSIC WG has years worth of things that aren't well defined in SDP that it's now taking the opportunity to define (a sort of "RAI 2.0"). And everything back to the W3C is blocked by these things that aren't well defined in SDP, meaning WebRTC isn't done until MMUSIC defines all these things in SDP that have been piling up for years. Is that accurate? If so, I agree that "scope management" would be a good thing to consider. --001a11c39d18ca604604e1e20115 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 10:57 AM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 19 July 2013 10:39, Pet= er Thatcher <pthatcher@google.co= m> wrote:
> So, are you trying to say "Look how hard this is to do with SDP. = =C2=A0We're not
> even done yet. =C2=A0It will be even harder without SDP"?

In the Atlanta meeting (Nov 2012) I remember waiting for those damned=
elevators with Justin. =C2=A0He said something like: "So, if we'd = chosen
comment 22 [CU-RTC-Web] do you think we'd be done by now?" =C2=A0I= was
quick to answer, "Of course not." =C2=A0After all, we'd only = made that
proposal 3-4 months earlier. =C2=A0I know that nothing gets done in less than a year, and this is not a small undertaking.

Since then, I've gained a more nuanced view. =C2=A0We've set an imp= ossibly
high bar for this specification, including all sorts of crazy
features: FEC, simulcast, layered codecs, congestion control,
undeployed codecs, multiplexing, and not to mention a new data
channel.

In reality, SDP never negotiated all that crap before. =C2=A0Worse, despite=
the existence of RFCs for most of these features, it turns out that
most implementations were proprietary. =C2=A0We couldn't even agree on = what
an m-line represents.

So, if asked the same question today, I'd probably have to say: "W= e'd
at least have had basic scenarios shipped. =C2=A0We might not have sorted out the hard cases like layered codecs, but we do have basic
functionality."

What we have this the complete antithesis of any project I've been
involved in over the past 10 years. =C2=A0It's gold-plating the pink squirrel.

If we want to ship this thing, then we should be managing scope, not
protecting it.

Slight aside, but is this a correct model = of what has happened with regards to scope?

The W3= C is waiting for the IETF RTCWEB WG. =C2=A0The RTCWEB WG is waiting for the= MMUSIC WG. =C2=A0 The MMUSIC WG has years worth of things that aren't = well defined in SDP that it's now taking the opportunity to define (a s= ort of "RAI 2.0"). =C2=A0And everything back to the W3C is blocke= d by these things that aren't well defined in SDP, meaning WebRTC isn&#= 39;t done until MMUSIC defines all these things in SDP that have been pilin= g up for years.=C2=A0

Is that accurate? =C2=A0If so, I agree that "scope= management" would be a good thing to consider.
--001a11c39d18ca604604e1e20115-- From adam@nostrum.com Fri Jul 19 12:06:49 2013 Return-Path: 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 ECC1211E81A2 for ; Fri, 19 Jul 2013 12:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ilyM2DQCT4jO for ; Fri, 19 Jul 2013 12:06:49 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6F11E8197 for ; Fri, 19 Jul 2013 12:06:42 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JJ6Yb6085810 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 14:06:34 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51E98E34.8060709@nostrum.com> Date: Fri, 19 Jul 2013 14:06:28 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Peter Thatcher References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97C41.5050208@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:06:50 -0000 On 7/19/13 13:47, Peter Thatcher wrote: > I think this is the real issue at hand: You value legacy interop more > than a usable API. This. *This* is why I've told you that you're misunderstanding everything. Don't take offense, just go back and read more carefully. I never said anything that implied that legacy interop is more valuable than a usable API. It's a nice strawman for you to build up and tear down, but you are arguing with a fictional character who is not me when you do so. What I'm trying to point out is that these goals are not at odds with each other. Your statement above implies that you have taken it as given that we can't do both -- that there is a tradeoff here to be made. If you take that as a fundamental principle, then I can see how nothing I say makes any sense. But they're not mutually exclusive goals. Keep that in mind, and go back to re-read what I've written. /a From pthatcher@google.com Fri Jul 19 12:14:12 2013 Return-Path: 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 3B0CF21E808D for ; Fri, 19 Jul 2013 12:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.233, 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 i5YEnjfvXbuA for ; Fri, 19 Jul 2013 12:14:11 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id A96C821E805D for ; Fri, 19 Jul 2013 12:14:09 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id t12so4574217pdi.35 for ; Fri, 19 Jul 2013 12:14:09 -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=3T1gLjwyTPjpk0Em7j8Udd5xpxCJlolGFTeWgFy3tiY=; b=jmSyZC+fmf4Nxn9gOfLJ2IAkTMLgjLx05O82q7n+hJNBm61P62WNC1enwi/BTPFxev W7BVS6JbYfkVzeIB1Hf682WJSWFAJJSa8Hr04pqtu5lkwSJlWOe0G5I08TQzaf+R+gPE O2wDUTCKBbvIeiooyklSS+R+Lhv8dckuqG426W23izovyD/hSDH2+S5dbOvtjQyCEqRj BpsxOrNOFPP6130soLg/n8UOy5hefueafELZSxhEfZcIrnAeI/JaeV+OwjTZfapNz/yT 1xkKPtsMIhKRZs1P+m1hz8K/fmnN/iEK53xkSEaKXuTTEXiTAxqQ3eSZix8U07rFgm1a T2Cg== 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=3T1gLjwyTPjpk0Em7j8Udd5xpxCJlolGFTeWgFy3tiY=; b=jIhZyqnqNB5nqkHnJXAfy03owQhhphhoIcxxiV3B5AdJqD7eJkYOJviw7yYEZBviLN +Wl+qsnC4qn2e92eFzyPOxy11UccCRnW5KacCROVCMOsE0THAD4TIsuI3whm0JLouuy8 oOeBULl/fBHTVIzJfFpLp1mAP/NvBWxcfjfIRaclC3Hz5a7V7cjossAiAKBJc3dRFR6b S+EJlbQGeuL8TqEb+ltWxjCvp7G/eYN2/cpqWyViYnH+v6b6qAAYlnvdH5rIDSDHG05z Mim+/p6VE4kKLspJhkpB/1QRqOUF9nwFlg1zGBDOsuIR0bRUpztKdSb83oOCbMnqtalM XK2g== X-Received: by 10.68.217.7 with SMTP id ou7mr18802096pbc.8.1374261249221; Fri, 19 Jul 2013 12:14:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 12:13:29 -0700 (PDT) In-Reply-To: <51E98AB5.3090209@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97C41.5050208@nostrum.com> <51E98AB5.3090209@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 12:13:29 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=e89a8ff2431996c5e104e1e221ce X-Gm-Message-State: ALoCoQlzEJeKdc4UIsi/HrxgxsE6ccUdCjdBaH46Ivg0uMQ6UETHkM3522Q9QqRzkn3N8oOjmuLLDXUOBbk9FjG/6cd7AJv5uz9eFu7eF9xqU0TN+H9HBpugEjGzvwpVFqmkViHLN6kDKxp+snEjZFdNs8MB1xZCgSXcyPq60LuzOFytPNSoSB0m/sxuFJi54ZU8bjUVxwjh Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:14:12 -0000 --e89a8ff2431996c5e104e1e221ce Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 11:51 AM, Adam Roach wrote: > On 7/19/13 13:47, Peter Thatcher wrote: > >> Do you really believe all of them are naive and full of hubris? >> > > No, I think they're using an API that is nowhere near finished yet, which > is necessarily going to be painful. The complaints are legitimate. > > "nowhere near finished yet"? Yikes. We just spent almost a year arguing about what an m-line is. What's your timeline for finishing? The scapegoating of SDP is what's misguided. Well, I guess we're going to have to agree to disagree, because from my perspective as a web developer and a browser implementer, the API being based on SDP Offer/Answer is the heart of the problem, and not just a scapegoat. I hope that we can do much better in a 2.0 API while maintaining legacy interop (make everyone happy), but of course I'll refrain from talking about that further until the right time has come. > > > /a > --e89a8ff2431996c5e104e1e221ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 11:51 AM, Adam Roach <= adam@nostrum.com&= gt; wrote:
On 7/19/13 13:47, Peter Thatcher wrote:<= br>
=C2=A0Do you really believe all of them are naive and full of hubris?

No, I think they're using an API that is nowhere near finished yet, whi= ch is necessarily going to be painful. The complaints are legitimate.


"nowhere near finished yet"?= =C2=A0Yikes. =C2=A0We just spent almost a year arguing about what an m-lin= e is. =C2=A0What's your timeline for finishing? =C2=A0=C2=A0
=
The scapegoating of SDP is what's misguided.

Well, I guess we're going to have to agree to disagree, because f= rom my perspective as a web developer and a browser implementer, the API be= ing based on SDP Offer/Answer is the heart of the problem, and not just a s= capegoat. =C2=A0I hope that we can do much better in a 2.0 API while mainta= ining legacy interop (make everyone happy), but of course I'll refrain = from talking about that further until the right time has come.=C2=A0

=C2=A0


/a

--e89a8ff2431996c5e104e1e221ce-- From pthatcher@google.com Fri Jul 19 12:43:24 2013 Return-Path: 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 B2D4111E81B2 for ; Fri, 19 Jul 2013 12:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.227, 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 XyH+GGKQZGXS for ; Fri, 19 Jul 2013 12:43:24 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78311E81AD for ; Fri, 19 Jul 2013 12:43:19 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq12so1444783pab.11 for ; Fri, 19 Jul 2013 12:43:18 -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=PvpbLkcOvfkH3EanBTafUSMWjV0vtLd8mLuanm0fp/8=; b=EpJ3N1X0ErcQYcgikPFwkDYGkzG2ucw52kShsNdDpFDPFqOTJ+PVaE3nCkV/kyT1w6 qxG73qgLlDc9V5KDbziQIrnSKDo3sioeCcC0WJ7Lcf3HUpxW6p1XKJa0jJQNyw3eajry 1w+11OqhNNF8t5g4mlPNB7evy79JZu2nxm68erUK5bbxpszp43yRLfB3dLh7o3mywkE8 2dtcDA8SJ8ZYJQ/bKa499t/RTfux2je/hEyJbVHSXQIruZ3jV+pRvloQfSF6WH/ndBLb isr7rIPu6KgZmviFcslKyJl8WVtzDOU/1p8lVl1+91tRj5ofx167ZJom6Ibf8EIR70pb 70Qw== 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=PvpbLkcOvfkH3EanBTafUSMWjV0vtLd8mLuanm0fp/8=; b=oVrnKlMFxxH3cxhH/NU5MJC7CxCDdxnuciuiBjrtW3aWL4seuQdXRhyT3dDCHFSnRx Wlvio6lcyvPJOQHsTwh/FxjxdpnM6SJf1sMSihFVYgKHPKQO6KtIkT5/+Dza4JjisjO6 Dzvwxkz8WqVt0xn9JFzkRCBergAjrdWb+/Iirom9+IX7CwPuL1/XHenX+RXZCJ7PzHYi wvhkdCAEtY7uSlr3/6fI6X5L4vUjsyW2924h9MHpL1biZF0dMY7sbcxHx76jDSKx0g+/ 29aoT/gmDeu06pEq/mh61yHwRccg4+5w1i9fh3HXp4sAy5kZICIPvSv+w02Zp63mf9se knEA== X-Received: by 10.66.142.5 with SMTP id rs5mr20107859pab.168.1374262998774; Fri, 19 Jul 2013 12:43:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 12:42:38 -0700 (PDT) In-Reply-To: <51E98E34.8060709@nostrum.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <51E97C41.5050208@nostrum.com> <51E98E34.8060709@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 12:42:38 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a11330f2aded74204e1e28938 X-Gm-Message-State: ALoCoQmeZ9IDO7tQUpUqaIQnVeCHsnhBTnyAUtCpZZvg5qzI2BMkjCAGxdjZq8bveSMvVBdjdBm6MNRWeXYFfdA9E8Ug/uY/gtWqWFCIdQOwaKmetnf4uuCbEtz7i//sj84bXEnenfoKTDchxgvZGY5Abw4M4xJJzOGg+xhb69zrZqgyuxkatPyuQiFL99qKQwMFX0vdXmSi Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:43:24 -0000 --001a11330f2aded74204e1e28938 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 12:06 PM, Adam Roach wrote: > On 7/19/13 13:47, Peter Thatcher wrote: > >> I think this is the real issue at hand: You value legacy interop more >> than a usable API. >> > > This. *This* is why I've told you that you're misunderstanding everything. > Don't take offense, just go back and read more carefully. I never said > anything that implied that legacy interop is more valuable than a usable > API. It's a nice strawman for you to build up and tear down, but you are > arguing with a fictional character who is not me when you do so. > > What I'm trying to point out is that these goals are not at odds with each > other. Your statement above implies that you have taken it as given that we > can't do both -- that there is a tradeoff here to be made. If you take that as a fundamental principle, then I can see how nothing I > say makes any sense. > > But they're not mutually exclusive goals. Keep that in mind, and go back > to re-read what I've written. > > You are claiming that there is no tradeoff between API usability and legacy interop. If that is the case, then why have we designed such a terribly unusable API? If we can have an API with both legacy interop and usability, then why didn't we create that API? If we can make an API that serves both sides (roughly, "web developers" and "legacy interop") well, why have we picked an API that only serves one well? I do believe that we can have an API that provides both good usability and legacy interop, and that can server both sides (and even more sides) well. But is most assuredly not the API we've designed so far, and it's not the API we're headed toward (at least not with "1.0"). I have hope for the 2.0 API, but let's not kid ourselves. The 1.0 API picked a side and ran with it. > /a > --001a11330f2aded74204e1e28938 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 12:06 PM, Adam Roach <= adam@nostrum.com&= gt; wrote:
On 7/19/13 13:47, Peter Thatcher wrote:<= br>
I think this is the real issue at hand: =C2=A0You value legacy interop more= than a usable API.

This. *This* is why I've told you that you're misunderstanding ever= ything. Don't take offense, just go back and read more carefully. I nev= er said anything that implied that legacy interop is more valuable than a u= sable API. It's a nice strawman for you to build up and tear down, but = you are arguing with a fictional character who is not me when you do so.
What I'm trying to point out is that = these goals are not at odds with each other. Your statement above implies t= hat you have taken it as given that we can't do both -- that there is a= tradeoff here to be made.
If you take that as a fundamental principle, then I can se= e how nothing I say makes any sense.

But they're not mutually exclusive goals. Keep that in mind, and go bac= k to re-read what I've written.


You are claiming that th= ere is no tradeoff between API usability and legacy interop. =C2=A0If that = is the case, then why have we designed such a terribly unusable API? =C2=A0= If we can have an API with both legacy interop and usability, then why didn= 't we create that API? =C2=A0If we can make an API that serves both sid= es (roughly, "web developers" and "legacy interop") wel= l, why have we picked an API that only serves one well?

I do believe that we can have an API that provides both= good usability and legacy interop, and that can server both sides (and eve= n more sides) well. =C2=A0But is most assuredly not the API we've desig= ned so far, and it's not the API we're headed toward (at least not = with "1.0"). =C2=A0I have hope for the 2.0 API, but let's not= kid ourselves. =C2=A0The 1.0 API picked a side and ran with it.
=C2=A0
=C2=A0
/a

--001a11330f2aded74204e1e28938-- From partha@parthasarathi.co.in Fri Jul 19 12:53:32 2013 Return-Path: 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 9020E11E812D for ; Fri, 19 Jul 2013 12:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 f5kX2OjBl0df for ; Fri, 19 Jul 2013 12:53:23 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [70.87.28.142]) by ietfa.amsl.com (Postfix) with ESMTP id 90D6611E8197 for ; Fri, 19 Jul 2013 12:53:23 -0700 (PDT) Received: from userPC (unknown [122.178.223.33]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 791C163818A; Fri, 19 Jul 2013 19:53:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1374263592; bh=treuQqXesS46ELmMaAcco/7JqqMSknLu0eKnrOtMpEw=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=XMND6plHZaVz1BhzsjS8mJ/l79TjawAu5Gv2yrCK8o6gtZA5Ofwua8ixNuXJr+jp0 VjkCJVvEb5/5NpkiWavvlNeXp4vrJFYEz+GZuCwexaAapw6seS0feSk6ePL8/xo++H sxcqMblqKycPdhWwWSuL3GVJ0yUvx+TDRKEBEpsk= From: "Parthasarathi R" To: "'Hadriel Kaplan'" , References: In-Reply-To: Date: Sat, 20 Jul 2013 01:22:52 +0530 Message-ID: <016a01ce84b9$911ee3e0$b35caba0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5/89qBZ+Ih6YT2QMSu6Dcc1OHJtwEurQtA Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.51E99928.004B, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:53:32 -0000 Hi Hadriel & all, I agree with Hadriel that DTLS-SRTP as MTI has market benefit but still I'm not seeing much difference in terms of end-user security. I was supporting DTLS-SRTP earlier as MTI as WebRTC signaling may takes place in HTTP. In reality, HTTPS is expected by webrtc operator as they are worried about Web signaling Security (on-path attack). In case of HTTPS based WebRTC signaling traffic is used, I'm not seeing any difference between DTLS-SRTP & SDES because it is possible to intercept the traffic by web provider (signaling server) in case the web provider is intended to do so as mentioned in Sec 5.7.1. of draft-ietf-rtcweb-security-arch-07. Dr.Evil website shall design as follows: -----Web Server & IdP----- | | | Browser------B2BMGW------Browser Back to back media gateway (B2BMGW) has the capability to terminate and originate DTLS-SRTP webrtc media traffic without informing browser. Please look into http://www.webrtc2sip.org/ for how easy to design such B2BMGW. The identity is not mandatory in WebRTC. Webrtc session request using HTTPS URL like https://apprtc.appspot.com/?r=80112689 works well and it has good web application like conference link. So, there is no much difference between DTLS-SRTP & SDES-SRTP in case of no identity scenario. Even if the identity is mandated using Idp, Dr.Evil provider shall mandate authoritative Idp as (@drevil.com) which helps to intercept the media in B2BMGW. I could not understand why Dr.Evil web provider will provide the mechanism for establishing webrtc session using third party identity provider. As of now, I'm not very clear how webrtc security trust model with DTLS-SRTP really benefit browser user in terms of security whereas SDES-SRTP compromise the security. I see the difference between SDES-SRTP & DTLS-SRTP in case HTTP origin. So apart of Hadriel compromise plan, some of the SDES compromise plan could be 1) forbid HTTP origin when SDES is requested by API 2) forbid HTTP origin entirely and allow SDES-SRTP as one of the security key mechanism. Let application selects its preferred security key mechanism. Thanks Partha > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Saturday, July 13, 2013 11:37 PM > To: rtcweb@ietf.org > Subject: [rtcweb] A compromise for SDES > > Howdy, > Someone's asked me to explain the compromise I plan on presenting in > Berlin now, so we have more time to argue over it or chew on it. The > reason I was going to wait is because I wanted to explain how I got to > the point of thinking such a compromise would make sense. So I'll try > to do that in this email, which will make this email long. Nothin' > much I can do about that. > > Obviously this is all my personal opinion, not that of my employer, and > not a statement claiming to be objective fact, etc. > > Background: > I think many people would agree that SDES has some benefits compared to > DTLS for those of us wishing to interface to the SIP world. Some of > those benefits are commercial/cost factors, some are more tangible like > reducing early media clipping. Whether you agree with such benefits or > not, so long as WebRTC could support SDES in a sufficiently-secure > manner, there'd be less concern over having it. Most of the arguments > against SDES have been directed at whether it could in fact be > "sufficiently secure". Personally I find most of the arguments against > it being secure enough to be essentially FUD, and/or also apply to > DTLS-SRTP. > > On the flip-side, I think the commercial/cost factor for SDES is not a > strong cause, because I believe the market will bear whatever the extra > cost may be. (I wasn't sure of this 2 years ago when this all started, > but I'm fairly confident of it now) And I think having only DTLS-SRTP > as MTI would have a marketing benefit for WebRTC as a technology, which > I value highly. > > Given those personal feelings, I didn't much care either way, so long > as a decision was made - although I still preferred having SDES to > avoid the early media clipping problem. So when I was going to present > on this topic back in the Vancouver meeting, my last slide basically > said: "If we support SDES and it turns out later we were wrong, we can > always rescind it". This was based on the notion that browsers get > updated all the time, especially for security issues. > > But later it occurred to me that's actually the Achilles' heel of > supporting SDES in WebRTC, for those of us wanting to gateway this > stuff to SIP. Imagine if it turns out we were wrong, and some > expected-or-unexpected vulnerability is exploited against some large > WebRTC service provider, and makes the news/slashdot. Browser vendors > would instantly have new code removing SDES support, and browsers in > devices would be updated virtually overnight - some users may take a > long time to upgrade their specific browsers on their specific devices > - but many of them would do so within days. That would be untenable > for a WebRTC service provider. Even the smaller Enterprises take a > long time to upgrade code on their servers, so even for them changing > their gateways to suddenly support DTLS-SRTP would be unrealistic. > Imagine what it would be for larger providers, who might even have to > deploy more servers to handle the sudden additional overhead of DTLS- > SRTP. Meanwhile a growing perc > entage of their users can no longer use the service. That's bad mojo. > > The things that a WebRTC-to-SIP service provider can control, and > arguably the much larger use-case for this stuff to begin with, are not > really true "browsers" anyway - they're web-based-framework device > Apps, provided by the service provider to begin with. I.e., the apps > they build using web application framework things like > PhoneGap/Cordova, Appcelerator Titanium, etc. I mean using a real > Browser is nice for ad-hoc stuff, like being able to click on a "talk > to a rep" button on a website, or a webex/meetecho type thing; but for > real communication "service", whether it be as a subscriber of a > traditional carrier, or Skype, or an employee of an Enterprise, or a > call-center attendant, or whatever - for those most people would never > want to have to open a browser just to receive/make calls. They'd give > you an app to use instead. > > So it's the app use-case that would benefit the most from SDES, > especially for issues like media clipping. And the app use-case > doesn't have the security concerns nor concerns for unforeseen > overnight updates. > > The Compromise: > So given that background, I was planning to propose that the security > doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a > statement that web-based application frameworks SHOULD also support > SDES. (with text about why and how, etc.) > > I don't think this is too controversial, because web-based frameworks > are never beholden to following browser behavior anyway - they're used > to build a native application, and native applications have a very > different security/threat model in practice. They're written for a > specific purpose, and installed by users from known sources for that > known purpose. Technically, afaik, nothing we do in RTCWEB WG or W3C's > WEBRTC group have any requirements/mandates for native applications > anyway - an app maker would just ignore something they don't think > applies to them - but I think web-based frameworks do generally try to > follow W3C models for Javascript APIs, and will likely read the IETF > RFCs for the media-layer stuff too. So I think having this SHOULD > statement would be beneficial. > > Or if the WG prefers, we could even write a separate doc on what a web- > based framework maker should consider supporting/not-supporting. (I can > imagine a few other things they might want to offer that a browser > can't) > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From partha@parthasarathi.co.in Fri Jul 19 13:02:18 2013 Return-Path: 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 256DC21E8091 for ; Fri, 19 Jul 2013 13:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] 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 H6ZagTZ19VD4 for ; Fri, 19 Jul 2013 13:02:09 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [70.87.28.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6A41411E80F4 for ; Fri, 19 Jul 2013 13:02:09 -0700 (PDT) Received: from userPC (unknown [122.178.223.33]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id A9BBF6381B0; Fri, 19 Jul 2013 20:02:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1374264127; bh=WHdCN4cMCh1sYaXFwE5PyesHyFCQjD2cU9WrZSe1Ees=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=PWNtMCLE4NcGbE/7duaQzlZE2pg8Z5DJPCElUcjjNSRUcViJGluvasKnnyjKxlZ9w qJW9EGBsJP0P/ghjnm5qQFsfXQ8jHpzI6K9xKsFk9CuLxqozatNIAIPuTRT4SGo8dn o6tr0mmHiu2Qi05RxMurxY7nX66/ATgW2xUduUsA= From: "Parthasarathi R" To: "'Eric Rescorla'" Date: Sat, 20 Jul 2013 01:31:47 +0530 Message-ID: <016c01ce84ba$d01edc70$705c9550$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6EusyxVasepmDlRxWaq8IsRz+L+w== Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0209.51E99B3F.0010, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: rtcweb@ietf.org Subject: [rtcweb] Nit in draft-ietf-rtcweb-security-05 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 20:02:18 -0000 Hi Eric, Sec 4.2.2 of draft-ietf-rtcweb-security-05 has the following statement twice: "Once consent is verified, there still is some concern about misinterpretation attacks as described by Huang et al.[huang-w2sp]." Regards Partha From fineberg@vline.me Fri Jul 19 15:05:49 2013 Return-Path: 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 EDAA521E8097 for ; Fri, 19 Jul 2013 15:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, HTML_MESSAGE=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 w8H43rf73+QM for ; Fri, 19 Jul 2013 15:05:44 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB0511E8198 for ; Fri, 19 Jul 2013 15:05:44 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so4733221pdj.17 for ; Fri, 19 Jul 2013 15:05:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=h6itxt8p4lQshvnI0ZZsAKYZlYdgHCis1fPfG09tCIE=; b=Jazys0a5eRrz7zpEJX9YL4SxWcmrsuhguTKL3zn0SKgOH8H6/Ua+A+LdJ5GJolNJI/ 3bMVKAmraSbVT9VVAfLZe+c9y177CLuqUZfdDTcy2CqN2eCzopU0W8E/ZokSReabUdvu 1oq74pN3PJrMBaOoGtv3TsfmHUWntxvY6w7NTC1uzIZpX3Lax4SRAiIHj6iQSpXXOLha EdANDgOlqFFEjcm2i1uuPRkbLwtzXYR/Vihw5v2B8YarMbND/MRV2bkaF3DOcEBjDi6i X7k8AqxQ0sTfJUHlS3kdgZ2gfXXZ0fsgQyE1PrB1aax9nrubDEnaZrTevnqLKuEQxDFU VOtA== X-Received: by 10.66.145.34 with SMTP id sr2mr20314179pab.94.1374271544051; Fri, 19 Jul 2013 15:05:44 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id nv6sm21574817pbc.6.2013.07.19.15.05.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 15:05:42 -0700 (PDT) Message-ID: <51E9B833.4080405@vline.me> Date: Fri, 19 Jul 2013 15:05:39 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bernard Aboba References: <51E7324A.3090405@vline.me> <51E80DA2.4030500@vline.me> <51E8B3B8.3090502@vline.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010405070100060106030201" X-Gm-Message-State: ALoCoQm+RZUmjv352Y5oj0rpWSLX2/haYaiK2C2iEfg46pG7DWKfguzw9Pefghl5l3vt/iLlfi4g Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 22:05:49 -0000 This is a multi-part message in MIME format. --------------010405070100060106030201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Bernard, I'll take a look at the other codecs to see what fields are needed and how to encode them in the header. Any help is appreciated as I'm not that familiar with H.264 and not at all familiar with H.265. Regards, Adam On 7/18/13 10:56 PM, Bernard Aboba wrote: > If we can support VP8/9 as well as H.264/5 SVC > that would be a start. It seems doable to me. > > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: > >> Bernard, >> >> Are there other codecs you are thinking should be supported? If it's >> generalized I would think we want to be able to cover all known >> scalable codecs. I'll look into the H264/SVC fields to see how to >> encode them in a generalized header. >> >> Regards, >> Adam >> >> On 7/18/13 7:40 PM, Bernard Aboba wrote: >>> I think it may be possible to generalize this. For example, for >>> H.264/SVC which can support temporal, spatial and quality >>> scalability, you would need the quality_id and dependency_id in >>> addition to the temporal_id (what you call the temporal layer index). >>> >>> ------------------------------------------------------------------------ >>> Date: Thu, 18 Jul 2013 08:45:38 -0700 >>> From: fineberg@vline.me >>> To: bernard_aboba@hotmail.com >>> CC: rtcweb@ietf.org; avtext@ietf.org >>> Subject: Re: [rtcweb] Fwd: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> >>> Bernard, >>> >>> Good question. I'm not familiar enough with the parameter >>> requirements of all other scalable codecs to be able to generalize. >>> If you'd like to help specify them, I'd be fine revising the draft >>> to generalize. >>> >>> Regards, >>> Adam >>> >>> On 7/17/13 8:26 PM, Bernard Aboba wrote: >>> >>> Since the need is not codec specific (e.g. it arises with any >>> codec supporting temporal, spatial and quality scalability), why >>> a VP8-specific RTP extension? >>> >>> ------------------------------------------------------------------------ >>> Date: Wed, 17 Jul 2013 17:09:46 -0700 >>> From: fineberg@vline.me >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] Fwd: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> >>> Hi, >>> >>> I'm working on WebRTC services and have found that while >>> developing services that forward VP8 video streams if we want to >>> take advantage of the VP8 temporal scaling we must get the >>> temporal layer information from the RTP header which requires us >>> to decrypt the SRTP packets. This is undesirable both because >>> the middle-box needs to have access to the keys as well as the >>> because of the added overhead of the decrypt/encrypt cycle. This >>> draft proposes an RTP header extension that will allow us to use >>> the VP8 temporal layer information included in the header >>> extension and therefore do forwarding without SRTP decryption. >>> Comments welcome. >>> >>> Regards, >>> Adam Fineberg >>> fineberg at vline.com >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> Date: Tue, 09 Jul 2013 10:02:05 -0700 >>> From: internet-drafts at ietf.org >>> >>> To: Adam Fineberg >>> >>> >>> >>> >>> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >>> has been successfully submitted by Adam Fineberg and posted to the >>> IETF repository. >>> >>> Filename: draft-fineberg-avtext-temporal-layer-ext >>> Revision: 00 >>> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >>> Creation date: 2013-07-08 >>> Group: Individual Submission >>> Number of pages: 6 >>> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >>> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >>> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >>> >>> >>> Abstract: >>> This document defines a mechanism by which packets of Real-Time >>> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >>> indicate, in an RTP header extension, the temporal layer information >>> about the frame encoded in the RTP packet. This information can be >>> used in a middlebox performing bandwidth management of streams >>> without requiring it to decrypt the streams. >>> >>> >>> _______________________________________________ rtcweb mailing >>> list rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> -- >>> Regards, >>> Adam >> -- Regards, Adam --------------010405070100060106030201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Bernard,

I'll take a look at the other codecs to see what fields are needed and how to encode them in the header.  Any help is appreciated as I'm not that familiar with H.264 and not at all familiar with H.265.

Regards,
Adam

On 7/18/13 10:56 PM, Bernard Aboba wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

-- 
Regards,
Adam


-- 
Regards,
Adam
--------------010405070100060106030201-- From fineberg@vline.me Fri Jul 19 15:12:58 2013 Return-Path: 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 9EBA721E8099 for ; Fri, 19 Jul 2013 15:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ZVEYscoa0qK7 for ; Fri, 19 Jul 2013 15:12:54 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 34CA821E805A for ; Fri, 19 Jul 2013 15:12:54 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id bi5so859772pad.36 for ; Fri, 19 Jul 2013 15:12:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=9GecPUwrpSOQTmG/q+OdLS5or3Gm+3/b/9/ZgxjEoto=; b=QDSw+jsTF3S2MSvQtMDQjbIMScZ0iRgSgKxrE90dGSp53ZtO+U+vSTeZmAzLe54J9V 4uThNeZzU2DvQmVAes5u5N8XGK111CxcjPs2mrRTLCw+9eCS5VM1ojC3dx/5jnKsOzlQ fGixxhC2L4yKV7XSkhGNtKU9qlduu19MC9L5NrTSaza0rX57+F30ruDz69sM/bGOBQf+ g001IOBuslk5ShRaCvXTuwsbCjZtIHhpLTPov2UPUFXbZjk77Wa46uWx4KmQIJ0uTPPG MndP4rgZcR3EWwtI5G5Fk8BetPq6HTEtl6nVy3o7hJ6wqMMtDaFM+tq4mAa0XmIYOyqP NflQ== X-Received: by 10.68.197.136 with SMTP id iu8mr19203950pbc.183.1374271973860; Fri, 19 Jul 2013 15:12:53 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id wr9sm21596801pbc.7.2013.07.19.15.12.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 15:12:52 -0700 (PDT) Message-ID: <51E9B9E1.3070006@vline.me> Date: Fri, 19 Jul 2013 15:12:49 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060303050707070804040104" X-Gm-Message-State: ALoCoQlrJyjwRNgabGLF/qLdI9usu7BW+gKXLdkwP/Qi6xnEQr9N17pSsCrfw5C+IQzG7ZOhjYYl Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 22:12:58 -0000 This is a multi-part message in MIME format. --------------060303050707070804040104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at all familiar with H.265. I'll review the reference and see what I can figure. It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly? There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension. Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: > Hi, > I also believe that 16 bits should be enough. For H.264 and VP8 that > has already been demonstrated. For H.265, some initial thoughts > below. Apologies for the word-count. > > The scalable version of H265 (called SHVC) is currently under > development. The current working draft can be found here: > http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. > Therein, the options for defining layering structures are > considerably more complex. To start, we have 3 bits for the temporal > ID in the NAL unit header of the H.265 version 1 (HEVC) base > specification (temporal scalability is already nicely supported in > version 1). Just like in SVC. In the scalable extension, the NAL > unit header contains a six bit field that points into a data structure > known as "Video Parameter Set" (VPS). Inside the VPS, those six bits > are mapped to to a position in a directed graph (specified through > "dimension_id[][]"), which tells you about the reference relationship > of the layer in question and its parent layer. One can recursively > follow the graph to determine what used to be called dependency_id, > quality_id, view_id, and whatnot. The six bit pointer field can (or: > is to be when possible) organized by the encoder such that it is > prudent for a middle box to throw away NAL units (belonging to layers) > with higher values of the six bit field first, before throwing away > NAL units with lower values. Relying on this feature, 3+6 bits == 9 > bits should be fine for the header extension. > > That said, the ordering by the encoder is just a recommendation, and > there may well be cases where different pruning strategies may be > advisable. For example, a layering structure could be constructed > that expands into two branches, one using 2D scalable tools only, the > other including view_id for multi view coding. By looking at the six > bit field alone, a middle box will not be able to meaningfully remove > NAL units belonging to one of the branches completely while pruning > the other branch. In order to meaningfully deal with that scenario, > there would be two options: one to represent the dimension_id[][] (and > associated control info) in the header extension, or require the > middle box to have access to the VPS and be able to interpret its > content. The further could take considerably more than 16 bits and we > would be talking about a variable length data structure. The latter > requires the middle box to have state and a mechanism to intercept the > VPS (through signaling---as the encrypted in-band VPS would not be > useful under the assumption that the middle box does not have the key > to the media---which is the motivation of the draft in the first > place). I personally don't mind at all the second mechanism, as I'm a > big fan of out-of-band parameter set transmission and any middle box > must be in the signaling path anyway to meaningfully manipulate RTP. > I do not like the first option due to its variable, and possibly > substantial, overhead. > > Stephan > > > From: Justin Uberti > > Date: Friday, 19 July, 2013 06:32 > To: Bernard Aboba > > Cc: "avtext@ietf.org " >, "rtcweb@ietf.org " > > > Subject: Re: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Agree those are the right codecs to design for. Since in each case > there are fairly low limits on the number of supported layers (i.e. 3 > spatial layers for SVC), I think it should be possible to pack the > temporal, spatial, quality layer ids into 16 bits. > > > On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > > wrote: > > If we can support VP8/9 as well as H.264/5 SVC > that would be a start. It seems doable to me. > > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: > >> Bernard, >> >> Are there other codecs you are thinking should be supported? If >> it's generalized I would think we want to be able to cover all >> known scalable codecs. I'll look into the H264/SVC fields to see >> how to encode them in a generalized header. >> >> Regards, >> Adam >> >> On 7/18/13 7:40 PM, Bernard Aboba wrote: >>> I think it may be possible to generalize this. For example, for >>> H.264/SVC which can support temporal, spatial and quality >>> scalability, you would need the quality_id and dependency_id in >>> addition to the temporal_id (what you call the temporal layer >>> index). >>> >>> ------------------------------------------------------------------------ >>> Date: Thu, 18 Jul 2013 08:45:38 -0700 >>> From: fineberg@vline.me >>> To: bernard_aboba@hotmail.com >>> CC: rtcweb@ietf.org ; avtext@ietf.org >>> >>> Subject: Re: [rtcweb] Fwd: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> >>> Bernard, >>> >>> Good question. I'm not familiar enough with the parameter >>> requirements of all other scalable codecs to be able to >>> generalize. If you'd like to help specify them, I'd be fine >>> revising the draft to generalize. >>> >>> Regards, >>> Adam >>> >>> On 7/17/13 8:26 PM, Bernard Aboba wrote: >>> >>> Since the need is not codec specific (e.g. it arises with >>> any codec supporting temporal, spatial and quality >>> scalability), why >>> a VP8-specific RTP extension? >>> >>> ------------------------------------------------------------------------ >>> Date: Wed, 17 Jul 2013 17:09:46 -0700 >>> From: fineberg@vline.me >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] Fwd: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> >>> Hi, >>> >>> I'm working on WebRTC services and have found that while >>> developing services that forward VP8 video streams if we >>> want to take advantage of the VP8 temporal scaling we must >>> get the temporal layer information from the RTP header which >>> requires us to decrypt the SRTP packets. This is undesirable >>> both because the middle-box needs to have access to the keys >>> as well as the because of the added overhead of the >>> decrypt/encrypt cycle. This draft proposes an RTP header >>> extension that will allow us to use the VP8 temporal layer >>> information included in the header extension and therefore >>> do forwarding without SRTP decryption. Comments welcome. >>> >>> Regards, >>> Adam Fineberg >>> fineberg at vline.com >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for >>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>> Date: Tue, 09 Jul 2013 10:02:05 -0700 >>> From: internet-drafts at ietf.org >>> >>> To: Adam Fineberg >>> >>> >>> >>> >>> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >>> has been successfully submitted by Adam Fineberg and posted to the >>> IETF repository. >>> >>> Filename: draft-fineberg-avtext-temporal-layer-ext >>> Revision: 00 >>> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >>> Creation date: 2013-07-08 >>> Group: Individual Submission >>> Number of pages: 6 >>> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >>> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >>> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >>> >>> >>> Abstract: >>> This document defines a mechanism by which packets of Real-Time >>> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >>> indicate, in an RTP header extension, the temporal layer information >>> about the frame encoded in the RTP packet. This information can be >>> used in a middlebox performing bandwidth management of streams >>> without requiring it to decrypt the streams. >>> >>> >>> _______________________________________________ rtcweb >>> mailing list rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> -- >>> Regards, >>> Adam >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext -- Regards, Adam --------------060303050707070804040104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm not at all familiar with H.265.  I'll review the reference and see what I can figure.  It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough.  For H.264 and VP8 that has already been demonstrated.  For H.265, some initial thoughts below.  Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under development.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerably more complex.  To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS).  Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer.  One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content.  The further could take considerably more than 16 bits and we would be talking about a variable length data structure.  The latter requires the middle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the media—which is the motivation of the draft in the first place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP.  I do not like the first option due to its variable, and possibly substantial, overhead.

Stephan   


From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

-- 
Regards,
Adam


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


 

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


-- 
Regards,
Adam
--------------060303050707070804040104-- From stewe@stewe.org Fri Jul 19 15:44:20 2013 Return-Path: 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 C9C0B11E81AC; Fri, 19 Jul 2013 15:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 oTa58rRyTcpr; Fri, 19 Jul 2013 15:44:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9B521F94DC; Fri, 19 Jul 2013 15:44:15 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) with Microsoft SMTP Server (TLS) id 15.0.731.16; Fri, 19 Jul 2013 22:44:13 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.146]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.42]) with mapi id 15.00.0731.000; Fri, 19 Jul 2013 22:44:13 +0000 From: Stephan Wenger To: Adam Fineberg Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOhJVBdM05O/fEXUeQN07SatH6lZlskQqA//+TZwA= Date: Fri, 19 Jul 2013 22:44:12 +0000 Message-ID: In-Reply-To: <51E9B9E1.3070006@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.202.147.60] x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(24454002)(377424004)(13464003)(377454003)(2473001)(189002)(479174003)(51914003)(16236675002)(76786001)(50986001)(83322001)(54316002)(81542001)(31966008)(36756003)(74706001)(53806001)(83072001)(76482001)(56776001)(4396001)(16406001)(69226001)(47976001)(59766001)(8558605003)(80022001)(47736001)(15202345003)(74876001)(81342001)(74502001)(19580405001)(49866001)(63696002)(76796001)(74366001)(56816003)(65816001)(51856001)(19580385001)(54356001)(76176001)(79102001)(77982001)(47446002)(77096001)(74662001)(66066001)(46102001)(19580395003)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB191; H:CO1PR07MB191.namprd07.prod.outlook.com; CLIP:71.202.147.60; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE0F0BEB9F95Dstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 22:44:20 -0000 --_000_CE0F0BEB9F95Dstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, From: Adam Fineberg > Date: Friday, 19 July, 2013 15:12 To: Stephan Wenger > Cc: Justin Uberti >, Bernard = Aboba >, "avtex= t@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at= all familiar with H.265. I'll review the reference and see what I can fig= ure. StW: Good luck :-) It seems though to me that you are suggesting that except in the simple cas= e, that the data for H.265 would not be well suited to a header extension, = am I understanding you correctly? There is no reason the middlebox couldn'= t get out of band signaling of the VPS as you mention but that would not be= within the scope of this header extension. StW: well, if you would copy the layer_id into your header extension (just = as you need to do for the simple case), a really smart middle box could use= this information just as a decoder uses it, assuming that it intercepted t= he VPS in the first place. Insofar, I wouldn't rule out the second option = on technical grounds. Whether any of the actual products would bother to d= o that, ever, is another question. I think the case ought to be documented= , though. I can help drafting text. While we are at it: doing this right could mean that you need multiple spec= s. First, a generic header extension mechanism dedicated to side informati= on required for pruning of RTP packet streams=97ideally not only for scalab= le video, although that is the main customer today. And second, for each "= payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v= 2 (including scalable and 3D extensions, which are not yet finalized), VP8,= and VP9 (I know little about the latter), plus Daala, and whatnot) a mappi= ng of the bits available in the generic header extension to the bits in the= payload itself (NAL header and VPS in case of H.265, NALU header in SVC, a= nd the fields you mention for VP8). Stephan Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling=97as the encrypted in-band VPS would not be useful under the assu= mption that the middle box does not have the key to the media=97which is th= e motivation of the draft in the first place). I personally don't mind at = all the second mechanism, as I'm a big fan of out-of-band parameter set tra= nsmission and any middle box must be in the signaling path anyway to meanin= gfully manipulate RTP. I do not like the first option due to its variable,= and possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal= -layer-ext-00.txt Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for = VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ avtext mailing list avtext@ietf.orghttps://www.ietf.org/mailman/listinf= o/avtext -- Regards, Adam --_000_CE0F0BEB9F95Dstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <14B1E0B74D0A2245A736553A748CABFC@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12 <= br> To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>,= "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd:= New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.t= xt

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm n= ot at all familiar with H.265.  I'll review the reference and see what= I can figure. 

StW: Good luck :-)  

It seems though to me that you ar= e suggesting that except in the simple case, that the data for H.265 would = not be well suited to a header extension, am I understanding you correctly?=   There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be = within the scope of this header extension.

StW: well, i= f you would copy the layer_id into your header extension (just as you need = to do for the simple case), a really smart middle box could use this inform= ation just as a decoder uses it, assuming that it intercepted the VPS in the first place.  Insofar, I wouldn't rule = out the second option on technical grounds.  Whether any of the actual= products would bother to do that, ever, is another question.  I think= the case ought to be documented, though.  I can help drafting text.
While we are= at it: doing this right could mean that you need multiple specs.  Fir= st, a generic header extension mechanism dedicated to side information requ= ired for pruning of RTP packet streams=97ideally not only for scalable video, although that is the main customer today. &nb= sp;And second, for each "payload" (at present we are talking abou= t H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions,= which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the b= its available in the generic header extension to the bits in the payload it= self (NAL header and VPS in case of H.265, NALU header in SVC, and the fiel= ds you mention for VP8).

Stephan


Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough.  For H.264 and VP8 = that has already been demonstrated.  For H.265, some initial thoughts = below.  Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under developm= ent.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_u= ser/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and t= here may well be cases where different pruning strategies may be advisable.=  For example, a layering structure could be constructed that expands = into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By lo= oking at the six bit field alone, a middle box will not be able to meaningf= ully remove NAL units belonging to one of the branches completely while pru= ning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the = dimension_id[][] (and associated control info) in the header extension, or = require the middle box to have access to the VPS and be able to interpret i= ts content.  The further could take considerably more than 16 bits and we would be talking about a variable le= ngth data structure.  The latter requires the middle box to have state= and a mechanism to intercept the VPS (through signaling=97as the encrypted= in-band VPS would not be useful under the assumption that the middle box does not have the key to the media=97wh= ich is the motivation of the draft in the first place).  I personally = don't mind at all the second mechanism, as I'm a big fan of out-of-band par= ameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP. &= nbsp;I do not like the first option due to its variable, and possibly subst= antial, overhead.

Stephan   


From: Justin Uberti <juberti@google.com&= gt;
Date: Friday, 19 July, 2013 06:32 <= br> To: Bernard Aboba <bernard_aboba@hotm= ail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, = "rtcweb@ie= tf.org" <rtcweb@iet= f.org>
Subject: Re: [rtcweb] Fwd: New Vers= ion Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in e= ach case there are fairly low limits on the number of supported layers (i.e= . 3 spatial layers for SVC), I think it should be possible to pack the temp= oral, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <= span dir=3D"ltr"> <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vl= ine.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For e= xample, for H.264/SVC which can support temporal, spatial and quality scala= bility, you would need the quality_id and dependency_id in addition to the = temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with = any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on = WebRTC services and have found that while developing services that forward = VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer infor= mation from the RTP header which requires us to decrypt the SRTP packets. T= his is undesirable both because the middle-box needs to have access to the = keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP he= ader extension that will allow us to use the VP8 temporal layer information= included in the header extension and therefore do forwarding without SRTP = decryption. Comments welcome.

Regards,=
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-0= 0.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineb= erg at vline.com> 


A new version of I-D, dr=
aft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-a=
vtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-=
layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer=
-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

--=20
Regards,
Adam


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



_______________________________________________
avtext mailing list
avtex=
t@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

--=20
Regards,
Adam
 --_000_CE0F0BEB9F95Dstewesteweorg_-- From fineberg@vline.me Fri Jul 19 15:54:15 2013 Return-Path: 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 6F52011E81CA for ; Fri, 19 Jul 2013 15:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 XaJw5Zao7mPN for ; Fri, 19 Jul 2013 15:54:11 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2D221F8FF3 for ; Fri, 19 Jul 2013 15:53:42 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rl6so4948863pac.29 for ; Fri, 19 Jul 2013 15:53:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=kNoA5LxJKZ20LHMjfuI3tGyrQXkybzJXu8+etVBNzk8=; b=gAIjVhi/5LH//QPzB2INyflpuLglbwgIu3vHNA1bvsXg9soDyTZ62cuHpJpuPDBNiK Q5pK/qc+Ew5WbPAmM+nEzpIOfA8dhNz/8gM5e2Zk6TvWaCWA2WXYnFlDVdRgGkkRhBPD zx6h06Mre/2end5zCVld8kpyRNRPjKXDpXJAfaZWqbAgyPUqLFXUk0IUgJGuIYabVDOe NwJp9NBcB1Q1Eb/GiBwY8zPBejJSjK6phaIL2cIi2n+iVhauEt3xn+sRFkfFvE51XFNZ x/7W1spnE+OE/MUi4Ar4Yq/o0oKCdu0RbO9v4+NU6tYMNjKkXDb05NtYH1J9HzE8AI9/ QETw== X-Received: by 10.67.21.229 with SMTP id hn5mr20615088pad.135.1374274421939; Fri, 19 Jul 2013 15:53:41 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id xl3sm21677782pbb.17.2013.07.19.15.53.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 15:53:40 -0700 (PDT) Message-ID: <51E9C371.2090905@vline.me> Date: Fri, 19 Jul 2013 15:53:37 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010603030307070406090203" X-Gm-Message-State: ALoCoQnoMZfNOpxgyk84WWfk9sfg8vx6bbULiGeS857ZOJL8IUj59Z0TcoSkWk1nrPjz7Snkv12m Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 22:54:15 -0000 This is a multi-part message in MIME format. --------------010603030307070406090203 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Stephan, On 7/19/13 3:44 PM, Stephan Wenger wrote: > Hi, > > From: Adam Fineberg > > Date: Friday, 19 July, 2013 15:12 > To: Stephan Wenger > > Cc: Justin Uberti >, > Bernard Aboba >, "avtext@ietf.org > " >, > "rtcweb@ietf.org " > > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Stephan, > > Thanks for the info and the reference. I'm not sure I follow as I'm > not at all familiar with H.265. I'll review the reference and see > what I can figure. > > StW: Good luck :-) > > It seems though to me that you are suggesting that except in the > simple case, that the data for H.265 would not be well suited to a > header extension, am I understanding you correctly? There is no > reason the middlebox couldn't get out of band signaling of the VPS as > you mention but that would not be within the scope of this header > extension. > > StW: well, if you would copy the layer_id into your header extension > (just as you need to do for the simple case), a really smart middle > box could use this information just as a decoder uses > it, assuming that it intercepted the VPS in the first place. Insofar, > I wouldn't rule out the second option on technical grounds. Whether > any of the actual products would bother to do that, ever, is another > question. I think the case ought to be documented, though. I can > help drafting text. Any help is appreciated. > While we are at it: doing this right could mean that you need multiple > specs. First, a generic header extension mechanism dedicated to side > information required for pruning of RTP packet streams—ideally not > only for scalable video, although that is the main customer today. > And second, for each "payload" (at present we are talking about > H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D > extensions, which are not yet finalized), VP8, and VP9 (I know little > about the latter), plus Daala, and whatnot) a mapping of the bits > available in the generic header extension to the bits in the payload > itself (NAL header and VPS in case of H.265, NALU header in SVC, and > the fields you mention for VP8). I was just thinking about that since it seems like the extension payload maybe completely specific and therefore not suitable for the same spec. The problem in my mind with taking the hierarchical a[[roach you mention is that I'm not sure what if any common data is suitable accross all codecs and since there is already a spec for the general header extension, the generic one you mention might be fairly redundant. I'm certainly open to your thoughts though. Regards, Adam > > Stephan > > > Any insights are appreciated. > > Regards, > Adam > > On 7/19/13 8:33 AM, Stephan Wenger wrote: >> Hi, >> I also believe that 16 bits should be enough. For H.264 and VP8 that >> has already been demonstrated. For H.265, some initial thoughts >> below. Apologies for the word-count. >> >> The scalable version of H265 (called SHVC) is currently under >> development. The current working draft can be found here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. >> Therein, the options for defining layering structures are >> considerably more complex. To start, we have 3 bits for the temporal >> ID in the NAL unit header of the H.265 version 1 (HEVC) base >> specification (temporal scalability is already nicely supported in >> version 1). Just like in SVC. In the scalable extension, the NAL >> unit header contains a six bit field that points into a data >> structure known as "Video Parameter Set" (VPS). Inside the VPS, >> those six bits are mapped to to a position in a directed graph >> (specified through "dimension_id[][]"), which tells you about the >> reference relationship of the layer in question and its parent layer. >> One can recursively follow the graph to determine what used to be >> called dependency_id, quality_id, view_id, and whatnot. The six bit >> pointer field can (or: is to be when possible) organized by the >> encoder such that it is prudent for a middle box to throw away NAL >> units (belonging to layers) with higher values of the six bit field >> first, before throwing away NAL units with lower values. Relying on >> this feature, 3+6 bits == 9 bits should be fine for the header extension. >> >> That said, the ordering by the encoder is just a recommendation, and >> there may well be cases where different pruning strategies may be >> advisable. For example, a layering structure could be constructed >> that expands into two branches, one using 2D scalable tools only, the >> other including view_id for multi view coding. By looking at the six >> bit field alone, a middle box will not be able to meaningfully remove >> NAL units belonging to one of the branches completely while pruning >> the other branch. In order to meaningfully deal with that scenario, >> there would be two options: one to represent the dimension_id[][] >> (and associated control info) in the header extension, or require the >> middle box to have access to the VPS and be able to interpret its >> content. The further could take considerably more than 16 bits and >> we would be talking about a variable length data structure. The >> latter requires the middle box to have state and a mechanism to >> intercept the VPS (through signaling—as the encrypted in-band VPS >> would not be useful under the assumption that the middle box does not >> have the key to the media—which is the motivation of the draft in the >> first place). I personally don't mind at all the second mechanism, >> as I'm a big fan of out-of-band parameter set transmission and any >> middle box must be in the signaling path anyway to meaningfully >> manipulate RTP. I do not like the first option due to its variable, >> and possibly substantial, overhead. >> >> Stephan >> >> >> From: Justin Uberti > >> Date: Friday, 19 July, 2013 06:32 >> To: Bernard Aboba > > >> Cc: "avtext@ietf.org " > >, "rtcweb@ietf.org " >> > >> Subject: Re: [rtcweb] Fwd: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Agree those are the right codecs to design for. Since in each case >> there are fairly low limits on the number of supported layers (i.e. 3 >> spatial layers for SVC), I think it should be possible to pack the >> temporal, spatial, quality layer ids into 16 bits. >> >> >> On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba >> > wrote: >> >> If we can support VP8/9 as well as H.264/5 SVC >> that would be a start. It seems doable to me. >> >> On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > > wrote: >> >>> Bernard, >>> >>> Are there other codecs you are thinking should be supported? If >>> it's generalized I would think we want to be able to cover all >>> known scalable codecs. I'll look into the H264/SVC fields to see >>> how to encode them in a generalized header. >>> >>> Regards, >>> Adam >>> >>> On 7/18/13 7:40 PM, Bernard Aboba wrote: >>>> I think it may be possible to generalize this. For example, for >>>> H.264/SVC which can support temporal, spatial and quality >>>> scalability, you would need the quality_id and dependency_id in >>>> addition to the temporal_id (what you call the temporal layer >>>> index). >>>> >>>> ------------------------------------------------------------------------ >>>> Date: Thu, 18 Jul 2013 08:45:38 -0700 >>>> From: fineberg@vline.me >>>> To: bernard_aboba@hotmail.com >>>> CC: rtcweb@ietf.org ; avtext@ietf.org >>>> >>>> Subject: Re: [rtcweb] Fwd: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> >>>> Bernard, >>>> >>>> Good question. I'm not familiar enough with the parameter >>>> requirements of all other scalable codecs to be able to >>>> generalize. If you'd like to help specify them, I'd be fine >>>> revising the draft to generalize. >>>> >>>> Regards, >>>> Adam >>>> >>>> On 7/17/13 8:26 PM, Bernard Aboba wrote: >>>> >>>> Since the need is not codec specific (e.g. it arises with >>>> any codec supporting temporal, spatial and quality >>>> scalability), why >>>> a VP8-specific RTP extension? >>>> >>>> ------------------------------------------------------------------------ >>>> Date: Wed, 17 Jul 2013 17:09:46 -0700 >>>> From: fineberg@vline.me >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] Fwd: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> >>>> Hi, >>>> >>>> I'm working on WebRTC services and have found that while >>>> developing services that forward VP8 video streams if we >>>> want to take advantage of the VP8 temporal scaling we must >>>> get the temporal layer information from the RTP header >>>> which requires us to decrypt the SRTP packets. This is >>>> undesirable both because the middle-box needs to have >>>> access to the keys as well as the because of the added >>>> overhead of the decrypt/encrypt cycle. This draft proposes >>>> an RTP header extension that will allow us to use the VP8 >>>> temporal layer information included in the header extension >>>> and therefore do forwarding without SRTP decryption. >>>> Comments welcome. >>>> >>>> Regards, >>>> Adam Fineberg >>>> fineberg at vline.com >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> Date: Tue, 09 Jul 2013 10:02:05 -0700 >>>> From: internet-drafts at ietf.org >>>> >>>> To: Adam Fineberg >>>> >>>> >>>> >>>> >>>> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> has been successfully submitted by Adam Fineberg and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-fineberg-avtext-temporal-layer-ext >>>> Revision: 00 >>>> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >>>> Creation date: 2013-07-08 >>>> Group: Individual Submission >>>> Number of pages: 6 >>>> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >>>> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >>>> >>>> >>>> Abstract: >>>> This document defines a mechanism by which packets of Real-Time >>>> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >>>> indicate, in an RTP header extension, the temporal layer information >>>> about the frame encoded in the RTP packet. This information can be >>>> used in a middlebox performing bandwidth management of streams >>>> without requiring it to decrypt the streams. >>>> >>>> >>>> _______________________________________________ rtcweb >>>> mailing list rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>>> -- >>>> Regards, >>>> Adam >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext > > -- > Regards, > Adam -- Regards, Adam --------------010603030307070406090203 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Stephan,

On 7/19/13 3:44 PM, Stephan Wenger wrote:
Hi,

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm not at all familiar with H.265.  I'll review the reference and see what I can figure. 

StW: Good luck :-) 

It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

StW: well, if you would copy the layer_id into your header extension (just as you need to do for the simple case), a really smart middle box could use this information just as a decoder uses it, assuming that it intercepted the VPS in the first place.  Insofar, I wouldn't rule out the second option on technical grounds.  Whether any of the actual products would bother to do that, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.

Any help is appreciated.

While we are at it: doing this right could mean that you need multiple specs.  First, a generic header extension mechanism dedicated to side information required for pruning of RTP packet streams—ideally not only for scalable video, although that is the main customer today.  And second, for each "payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the bits available in the generic header extension to the bits in the payload itself (NAL header and VPS in case of H.265, NALU header in SVC, and the fields you mention for VP8).

I was just thinking about that since it seems like the extension payload maybe completely specific and therefore not suitable for the same spec.  The problem in my mind with taking the hierarchical a[[roach you mention is that I'm not sure what if any common data is suitable accross all codecs and since there is already a spec for the general header extension, the generic one you mention might be fairly redundant.

I'm certainly open to your thoughts though.

Regards,
Adam


Stephan


Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough.  For H.264 and VP8 that has already been demonstrated.  For H.265, some initial thoughts below.  Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under development.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerably more complex.  To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS).  Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer.  One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content.  The further could take considerably more than 16 bits and we would be talking about a variable length data structure.  The latter requires the middle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the media—which is the motivation of the draft in the first place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP.  I do not like the first option due to its variable, and possibly substantial, overhead.

Stephan   


From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

-- 
Regards,
Adam


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




_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

-- 
Regards,
Adam
 

-- 
Regards,
Adam
--------------010603030307070406090203-- From fluffy@iii.ca Fri Jul 19 17:52:43 2013 Return-Path: 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 4FD9A21E804C for ; Fri, 19 Jul 2013 17:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, 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 BxPmauGDL51V for ; Fri, 19 Jul 2013 17:52:35 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 30DC511E81D2 for ; Fri, 19 Jul 2013 17:52:31 -0700 (PDT) Received: from sjc-vpn5-843.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0CBD222E1F3; Fri, 19 Jul 2013 20:52:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Fri, 19 Jul 2013 17:52:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <644AB0EE-8889-4940-BA88-33EA653D44DC@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> To: Martin Thomson X-Mailer: Apple Mail (2.1508) Cc: "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 00:52:43 -0000 On Jul 19, 2013, at 9:54 AM, Martin Thomson = 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.=20 From fluffy@iii.ca Fri Jul 19 17:54:48 2013 Return-Path: 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 023F321F8C65 for ; Fri, 19 Jul 2013 17:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.352, 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 ISBGXYJkKR-t for ; Fri, 19 Jul 2013 17:54:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 041A911E81E3 for ; Fri, 19 Jul 2013 17:53:56 -0700 (PDT) Received: from sjc-vpn5-843.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5352922E1FA; Fri, 19 Jul 2013 20:53:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Fri, 19 Jul 2013 17:54:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <466E66D9-80CD-4AD5-A671-F562C186C3C9@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> To: Peter Thatcher X-Mailer: Apple Mail (2.1508) Cc: "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 00:54:48 -0000 On Jul 19, 2013, at 10:18 AM, Peter Thatcher = wrote: >=20 > It's interesting that most or your list of things that needed to be = solved without SDP (simulcast, FEC, correlation of RTP streams with = MediaStreamTracks, glare) still haven't been solved for WebRTC even with = SDP, despite many months (years?) of effort. =20 >=20 Peter, with the exception of Simulcast, which of these do you think has = not been solved in SDP when not using bundle?=20 From pthatcher@google.com Fri Jul 19 17:57:27 2013 Return-Path: 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 41F4621E8056 for ; Fri, 19 Jul 2013 17:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.221, 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 mqm4pp-aKEww for ; Fri, 19 Jul 2013 17:57:26 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C721E804C for ; Fri, 19 Jul 2013 17:57:26 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so4999814pbb.19 for ; Fri, 19 Jul 2013 17:57:26 -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=xz+eJ3jrwgFS/xu4CqsgyjBhx9tv7riMu7ujaIAz7tU=; b=DO9syMEOwLw7XqyytY9vizFfaM80oNDiLPbmAN2nw0KL84hI262Ek29GEeAZ9unCY0 2fggY91TezPTmI94LDRh5TBfz+jh8rTMrVEIn3rQSqcdJERO3yFSjkdJKv4jk/BYDrGT zNegD30pmFsskBueQSjZZzl7+keLotjKDgIeCb6vOeDyKkw42UP0+gLum4eUVTuXflQY jzwCJ/N9GCaldT3BsNkk5sI8eqSmM+7ExIoE3HUe2he33H5dRKkD1Sp28+Aryfb8lHfn cwaqD3Or7CYytQ+AkHB6iUD7zcKIa1O7TCCvLtG5QDUJm/AHV+eyy0oJCF6Oh1WQurWn YmMA== 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=xz+eJ3jrwgFS/xu4CqsgyjBhx9tv7riMu7ujaIAz7tU=; b=LhBklAXJfaalHc0IjT0KNQY5LfsHGpI0s7XzfRMTccahieu4RBi+tEVR/69+S0CD++ AdcO2iXGDSqJzBu+Bov97rxsKXdMnIoaaeo00gVLhQgosG/N5U6EMLiOrtJ8qxmZJQ7k 93gyLu/q3ZB7gCjv80d10g/bckZyxZDGk5iijvDGcnXEd0+6IO92JJIAB/3efKmofH6h /rj+Eqyu9+qvj1OiU5IBwxNGY+vO43de7mS9VZgVEjrgLpiYO+9JGW8Kdh3U51I5Z6z5 ryhqRAtiOkaS/i8Mz+0vufjJ7HMgbgwEXELs/mZspLSYkLTS5YIsvii/kX3Ucaq7UwXu sKPA== X-Received: by 10.68.104.196 with SMTP id gg4mr20105434pbb.25.1374281845468; Fri, 19 Jul 2013 17:57:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 17:56:45 -0700 (PDT) In-Reply-To: <466E66D9-80CD-4AD5-A671-F562C186C3C9@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <466E66D9-80CD-4AD5-A671-F562C186C3C9@iii.ca> From: Peter Thatcher Date: Fri, 19 Jul 2013 17:56:45 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7b6705b938996004e1e6ed2f X-Gm-Message-State: ALoCoQlUW5XejPCDrtVS/Y/68SXpsFRhM51Z4VVhHHcnozzVmqfhDoFPV2O1L+3gEvz8zH/w7xRhbFJIrxGp+gXJV01juQ5BiZLGQ1vqcDYjLSIuRmsagO4k4iLc87y5Lm3+pSntkLEPGhYVy7xRYcXES1x3TKIWy2UZmx14dwMSHh3PhmSLGvzjYGQNbd7mb85h6piK3rcH Cc: "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 00:57:27 -0000 --047d7b6705b938996004e1e6ed2f Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 5:54 PM, Cullen Jennings wrote: > > On Jul 19, 2013, at 10:18 AM, Peter Thatcher wrote: > > > > > It's interesting that most or your list of things that needed to be > solved without SDP (simulcast, FEC, correlation of RTP streams with > MediaStreamTracks, glare) still haven't been solved for WebRTC even with > SDP, despite many months (years?) of effort. > > > > Peter, with the exception of Simulcast, which of these do you think has > not been solved in SDP when not using bundle? > > > Has FEC been defined for WebRTC? Has glare been solved? Has mapping of RTP streams with MediaStreamTracks been resolved (with the exception of the "unity plan" which has not yet been approved)? I think the whole list I gave is still unsolved/unresolved. --047d7b6705b938996004e1e6ed2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 5:54 PM, Cullen Jennings = <fluffy@iii.ca>= ; wrote:

On Jul 19, 2013, at 10:18 AM, Peter Thatcher <pthatcher@google.com> wrote:

>
> It's interesting that most or your list of things that needed to b= e solved without SDP (simulcast, FEC, correlation of RTP streams with Media= StreamTracks, glare) still haven't been solved for WebRTC even with SDP= , despite many months (years?) of effort.
>

Peter, with the exception of Simulcast, which of these do you think h= as not been solved in SDP when not using bundle?



Has FEC been defined for WebRTC? =C2= =A0
Has glare been solved?
Has mapping of RTP streams w= ith MediaStreamTracks been resolved (with the exception of the "unity = plan" which has not yet been approved)?

I think the whole list I gave is still unsolved/unresol= ved.=C2=A0

=C2=A0

--047d7b6705b938996004e1e6ed2f-- From fluffy@iii.ca Fri Jul 19 17:57:27 2013 Return-Path: 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 544EF21E804C for ; Fri, 19 Jul 2013 17:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 gBbKXU9wkbrK for ; Fri, 19 Jul 2013 17:57:21 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7D47021F9F50 for ; Fri, 19 Jul 2013 17:57:21 -0700 (PDT) Received: from sjc-vpn5-843.cisco.com (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 73D1C509B6; Fri, 19 Jul 2013 20:57:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Fri, 19 Jul 2013 17:57:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> To: Matthew Kaufman (SKYPE) X-Mailer: Apple Mail (2.1508) Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 00:57:27 -0000 On Jul 19, 2013, at 11:40 AM, Matthew Kaufman (SKYPE) = wrote: > From: Martin Thomson [mailto:martin.thomson@gmail.com] >>=20 >> Negotiation is a hole. A vast, soul-sucking, waste of time. >=20 > And negotiation over SDP requires a trip to MMUSIC every time you = think of something new, too. That's a soul-sucking waste of time = *itself*. >=20 > Matthew Kaufman Better than a trip to W3C, IETF, and XSF From pthatcher@google.com Fri Jul 19 18:01:31 2013 Return-Path: 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 D4BB621E8064 for ; Fri, 19 Jul 2013 18:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[AWL=0.216, 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 Bry0QDa6n+HU for ; Fri, 19 Jul 2013 18:01:31 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8B121E8056 for ; Fri, 19 Jul 2013 18:01:31 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so4776676pdd.20 for ; Fri, 19 Jul 2013 18:01:31 -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=Y0QnFsKASv6QijmBLKrqTRv/JjnHohFNGsvwXxw6jcY=; b=Ccy804TKbNwyuBU8q/uB0XMojGY4PXMNO7D0FE/I+dOlncBgbv8x2VHImqljK3JdhL mzKT1HGz0My2EXGK9iQ+L8n2+N0Mj9k1hbhRhQBNVMi3VczrAZb+PPA2qHJsF47e1q4l ZGzq2SO9DGJwYJ66n691nJzA/PEX7GdEzXshLB1HPhkf8D7PdMQ535p4lwcYoa8cUc2Z HVyK/y6NXHlFAdNjB8pjH9FLuprig1k9bg26CTZ/PbK9kYI8fGTTb55+/yxPrmkns9Yc 7DQieTXjnEGtARH3xY8IPN7SYynF62SyPC4nIANpDGtjlzgbPaeHquvkmfg2tQhAs5yB WY7Q== 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=Y0QnFsKASv6QijmBLKrqTRv/JjnHohFNGsvwXxw6jcY=; b=GDMK2vMqAw7CCSn9VRcvz+DC5Mi0PdmSH+toCPAnQhjFwDdcAjQIKd7CenjavCNCpp I7QP7RSK7RXf3LTswsX3yy3/K3ueM4yj8+K0gB6UzWE0ouWCx1nlDxx32EhU7vB/QH3q bxGGDm1Trn1JpL2PSiMqM7nMoxStEtD3f4c/z/qUWCK4l5XxF1kT4HjDEWBXsea6zw3e h4gA85s8E2lwQrwXBYCffOW7ZNTtDuCNypzbJlFsGsZECl8IOuvWjNdAJZpd9YYyNpHH OJFRA1BP5fOBlsH2xTkIerXovwyagdGbpljVhMjJ5jDSL9BRDh2ZrnTmf1hw0d2pIbpS GosQ== X-Received: by 10.68.217.7 with SMTP id ou7mr19861519pbc.8.1374282091011; Fri, 19 Jul 2013 18:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 18:00:49 -0700 (PDT) In-Reply-To: <644AB0EE-8889-4940-BA88-33EA653D44DC@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <644AB0EE-8889-4940-BA88-33EA653D44DC@iii.ca> From: Peter Thatcher Date: Fri, 19 Jul 2013 18:00:49 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=e89a8ff24319db461b04e1e6fbfd X-Gm-Message-State: ALoCoQk8BIDD6jdUAVJLHBisdIDgphNee6QVTfhnIbrnmc6MD9SxHcxUCO5GlU8z+BN5/kYQBVGzu7jAGeQoGecOX6OasWbEHIeqNlWOgxFdlDRBAva3dGPJbn9F9xHPRPJzQ21c0HPH7+DV9ZTFcDCDQePrGiMbg47jOLq8rB5u/mf/RxcZhaxp/Y1+stxGdPBFupnjr8Z0 Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 01:01:31 -0000 --e89a8ff24319db461b04e1e6fbfd Content-Type: text/plain; charset=UTF-8 The logic of how to talk to the video conferencing system doesn't need to be backed into the browser. If the API provides enough control the JS, the web app can contain the logic to talk to the video conferencing system. I know I'm going to start sounding like a broken record, but you brought up video conferencing systems as an example, so I will say it again: there are are video conferencing systems that don't use SDP for signalling. For example, there are video conferencing systems that use Jingle for signalling. Would I expect the logic of how to speak to that video conferencing system to be baked into the browser? No, I think I'd prefer it to be built into a web app built on top of a good API. Why should SDP-based video conferencing systems be treated special? On Fri, Jul 19, 2013 at 5:52 PM, Cullen Jennings wrote: > > On Jul 19, 2013, at 9:54 AM, Martin Thomson > 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. > > > > --e89a8ff24319db461b04e1e6fbfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The logic of how to talk to the video conferencing system = doesn't need to be backed into the browser. =C2=A0If the API provides e= nough control the JS, the web app can contain the logic to talk to the vide= o conferencing system. =C2=A0

I know I'm going to start sounding like a broken record,= but you brought up video conferencing systems as an example, so I will say= it again: there are are video conferencing systems that don't use SDP = for signalling. =C2=A0For example, there are video conferencing systems tha= t use Jingle for signalling. =C2=A0Would I expect the logic of how to speak= to that video conferencing system to be baked into the browser? =C2=A0No, = I think I'd prefer it to be built into a web app built on top of a good= API. =C2=A0Why should SDP-based video conferencing systems be treated spec= ial?


On Fri, = Jul 19, 2013 at 5:52 PM, Cullen Jennings <fluffy@iii.ca> wrote:<= br>

On Jul 19, 2013, at 9:54 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> Negotiation is a hole. =C2=A0A vast, soul-sucking, waste of time.

That's might be closer to true when you control both ends, like S= kype.

It's not true when a browser from one vendor running an application fro= m a scone vendor needs to talk to video conferencing system from a third ve= ndor.




--e89a8ff24319db461b04e1e6fbfd-- From pthatcher@google.com Fri Jul 19 18:02:05 2013 Return-Path: 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 4188321E8064 for ; Fri, 19 Jul 2013 18:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.211, 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 YxVQY4xk8EuW for ; Fri, 19 Jul 2013 18:02:04 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDFA21E8056 for ; Fri, 19 Jul 2013 18:02:04 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so4801071pdi.2 for ; Fri, 19 Jul 2013 18:02:04 -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=I2phMixAN0jU0lAkHsxd+kvrtW7wF3P22EF6nHIMFOQ=; b=iYwK6DDWZ47ZAGs7pf8U1I4tTHBg/Mn80KxcZEy1kd4lqNjqHM8nAESQ6FtZUkDqaI dFpAaDSAB/jResp3V10vnZcw8DiSqWgu1EXOJli7+eoQMi32ev4q6IlcsAoteURJH/xV S7qn8HbI6RI5RNwudjMCUBtDBwWAjFy+rq4tdwQ/dERN/nIYfY/2SCIPatYrhxbGcprW +4os09A6R0NMcHgHm33oGkjMetOAAw0yS54cb8gpV4jrDTRPvhzwqgtC7HEgrAjpOrPU whbslzyXQigJuvGudVryisLI7QWDTW9Owwww/sgRXdVaB5zR8KYZvIMnfGhEGoZyKOdr 3lXw== 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=I2phMixAN0jU0lAkHsxd+kvrtW7wF3P22EF6nHIMFOQ=; b=clavRaPuKw7GXup5RA+G0A1HMfktD20Z7J31iGELykkmxp7l3JIaUMILIrBl/yZjim nbp29oc8lFyhHpXfkjV8Ve3T+eHXs92eWcu16/8uFY/43WVBkWg1xlQrqcUxkfNxeyge jjGqvVOtOueNjiHM2QJ6rjwyr9cPN9ipo3vFdEyNLVMk+znUbvGncwx+vW6Nb/TL7FEp YhASl8F1R2sWiwbjO3iMr5FS6d6ppMArq0y4ADau2UQZ0p4TGxJxaM58GgdVa0yhBD+L fy8WCNb1qhMLx09lvfGURW7XTSUa7JBFTsy/JF5r1qE4NdgnksBzplosIX7q0Yw6bif5 bihw== X-Received: by 10.68.29.2 with SMTP id f2mr19764966pbh.184.1374282124331; Fri, 19 Jul 2013 18:02:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 18:01:24 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 18:01:24 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=bcaec520f3b9d7cd2004e1e6fd2e X-Gm-Message-State: ALoCoQl3E8BJVvGS9V632Z3UGNmmJaRmgiSv050DD/rBArQTI9SHAR5dccS2TbOTYFVuRr49k/PyrXhf5zCfS5qjo04YyllUw/d5JBHmrsp/91TBJ3wb5YEP+N6a9A1xXqfDsaNPAGOTht/IuBn5L0T5E1LGuN6THmriv7nFZFvgWAE7bKNVlbhCdk4vS5zegJLQCkHPeZmg Cc: "" , "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 01:02:05 -0000 --bcaec520f3b9d7cd2004e1e6fd2e Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 5:57 PM, Cullen Jennings wrote: > > On Jul 19, 2013, at 11:40 AM, Matthew Kaufman (SKYPE) < > matthew.kaufman@skype.net> wrote: > > > From: Martin Thomson [mailto:martin.thomson@gmail.com] > >> > >> Negotiation is a hole. A vast, soul-sucking, waste of time. > > > > And negotiation over SDP requires a trip to MMUSIC every time you think > of something new, too. That's a soul-sucking waste of time *itself*. > > > > Matthew Kaufman > > Better than a trip to W3C, IETF, and XSF > That's definitely a matter of opinion. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec520f3b9d7cd2004e1e6fd2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 5:57 PM, Cullen Jennings = <fluffy@iii.ca>= ; wrote:

On Jul 19, 2013, at 11:40 AM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:

> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>
>> Negotiation is a hole. =C2=A0A vast, soul-sucking, waste of time.<= br> >
> And negotiation over SDP requires a trip to MMUSIC every time you thin= k of something new, too. That's a soul-sucking waste of time *itself*.<= br> >
> Matthew Kaufman

Better than a trip to W3C, IETF, and XSF

That's definitely a matter of opinion.
=C2=A0

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

--bcaec520f3b9d7cd2004e1e6fd2e-- From fluffy@iii.ca Fri Jul 19 18:11:04 2013 Return-Path: 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 51F3E21E80B8 for ; Fri, 19 Jul 2013 18:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 gPumHcmpkQ3R for ; Fri, 19 Jul 2013 18:10:58 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDB321E8056 for ; Fri, 19 Jul 2013 18:10:51 -0700 (PDT) Received: from sjc-vpn5-843.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A3D6922E1F3; Fri, 19 Jul 2013 21:10:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Fri, 19 Jul 2013 18:10:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <466E66D9-80CD-4A D5-A671-F562C186C3C9@iii.ca> To: Peter Thatcher X-Mailer: Apple Mail (2.1508) Cc: "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 01:11:04 -0000 On Jul 19, 2013, at 5:56 PM, Peter Thatcher = wrote: >=20 >=20 >=20 > On Fri, Jul 19, 2013 at 5:54 PM, Cullen Jennings = wrote: >=20 > On Jul 19, 2013, at 10:18 AM, Peter Thatcher = wrote: >=20 > > > > It's interesting that most or your list of things that needed to be = solved without SDP (simulcast, FEC, correlation of RTP streams with = MediaStreamTracks, glare) still haven't been solved for WebRTC even with = SDP, despite many months (years?) of effort. > > >=20 > Peter, with the exception of Simulcast, which of these do you think = has not been solved in SDP when not using bundle? >=20 >=20 >=20 I asked about SDP, not WebRTC. The thing that is making this take a long = time is you don't want to use SDP.=20 > Has FEC been defined for WebRTC? =20 yes, that is defined for SDP O/A > Has glare been solved? yes > Has mapping of RTP streams with MediaStreamTracks been resolved (with = the exception of the "unity plan" which has not yet been approved)? This is obviously trivial if not using bundle. Any version of MSID would = work. It's only complicated by bundle >=20 > I think the whole list I gave is still unsolved/unresolved.=20 I disagree. They are only unresolved because we want to add bundle and = that was a major change to RTP resulting in a bunch of work needing to = be done to see how that impacted SDP.=20 >=20 > =20 >=20 From fluffy@iii.ca Fri Jul 19 18:20:03 2013 Return-Path: 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 31E9311E8191 for ; Fri, 19 Jul 2013 18:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 hgm4+LHEgeRK for ; Fri, 19 Jul 2013 18:19:58 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5284511E8160 for ; Fri, 19 Jul 2013 18:19:58 -0700 (PDT) Received: from sjc-vpn5-843.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9181C22E1FA; Fri, 19 Jul 2013 21:19:57 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Fri, 19 Jul 2013 18:20:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0D2B47D9-25BF-40C1-AC41-DF65093A6B94@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> To: Peter Thatcher X-Mailer: Apple Mail (2.1508) Cc: rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 01:20:03 -0000 Thanks,=20 I will note that over half of that very small sample set is folks that = have been long termed involved in SIP and VoIP so, uh, might not be a = representative sample of type of people you are portraying it as.=20 On Jul 19, 2013, at 7:51 AM, Peter Thatcher = wrote: > Here you go: >=20 >=20 >=20 >=20 > On Fri, Jul 19, 2013 at 7:00 AM, Cullen Jennings = wrote: > Can someone please email a full copy of the spreadsheet to the list so = it is in the archives - thanks >=20 > On Jul 9, 2013, at 3:18 AM, I=F1aki Baz Castillo = wrote: >=20 > > 2013/7/9 Stefan H=E5kansson LK : > >> I want to be very clear and careful on what I say. So I am = repeating: > >> > >> * My comment that I think Eric is right in that there is consensus = on > >> providing APIs that allow most use-cases to be met without SDP = mangling > >> is meant only in that context: SDP O/A is kept (and PeerConnection = more > >> or less as is and so on). > > > > Hi Stefan, > > > > You insist that "there is consensus on keeping SDP O/A but providing = a > > better API". Given current discussions IMHO it is clear there is not > > such a consensus (not at all). Or may be you are just talking about > > two years ago in some IETF meeting (if so I'm sorry). > > > > Please review the results in > > = https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdHl= ZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1 > > > > Bad for advanced stuff: 94% > > OK for 1.0: 40% > > > > IMHO such a result indicates all but "let's keep SDP O/A and improve = a > > bit the API" (I mean now, in July 2013). > > > > > > Best regards. > > > > > > > > -- > > I=F1aki Baz Castillo > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > From pthatcher@google.com Fri Jul 19 18:21:22 2013 Return-Path: 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 26EB711E81AA for ; Fri, 19 Jul 2013 18:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.206, 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 XHgvi1ARMD6K for ; Fri, 19 Jul 2013 18:21:21 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 807C911E8186 for ; Fri, 19 Jul 2013 18:21:21 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md12so4982695pbc.30 for ; Fri, 19 Jul 2013 18:21:21 -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=cpl9Ielwb3lL3bASyu/u09GlO+r/F3+57y+11MuRyus=; b=RukHdQo/mRyp/h+1+1WW8xvqagw5wbAYtXTuMQAbyhaMGb3krUiNP5q8XWMq3uc8XN TuLooyohwcVifZ/WtwvdxCDus661WQJotf4FwmzkG3jYcDyq1eREY/OuNtvDBCh/es+d 7uc0IcPqbX75ON3SJF5VSCGMJhDeZDLlvus2c4noGQZ6pCqEsTxzymTRTNk+xwzrzGxI j6HTEBElcl7OVl/Cu7fqbDePZ8ZrXpvNsOcVa8zbUzMD8dePzD7kTHva+oc5YDCej57x jFjwKQt49FPfeBwGVuhI038tomSWE3gkmT4xyhiWhPwziiosWKJ/XNaPRcMZL3eoTddG oApA== 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=cpl9Ielwb3lL3bASyu/u09GlO+r/F3+57y+11MuRyus=; b=dIPWlt6FS3JdyZKqoBeKa7BqOxVpQMANRVuVaCJCQ23whiuEvu422qs5vsDXm4s1Lh RfiurW9DwulyGxvRFi8ABQ+14oqbd2C1ONtR51msK5Zw9IHiI8dQuuhiyKOmciEtrIKy IT2rYj39wpXxdCBKplfghamRtQiaHBG1FjuhE/TzqBvWIEKlDRNk/OJNop9KODfQp9fr yGQDO2etzBm8YLoMz3sTcFFV8T3cLNfSAL9iDUKNM7eRI92FDczluKdyWja0nmN6PZ+x JYIfZPT09DrnHWJY8+4s8bK9qyFRZYc7W1iqpwwi7CuKZYLdFhNAmy8UCkO2zJnsxwwv 6USQ== X-Received: by 10.66.14.196 with SMTP id r4mr21183376pac.57.1374283280948; Fri, 19 Jul 2013 18:21:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 18:20:40 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> From: Peter Thatcher Date: Fri, 19 Jul 2013 18:20:40 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=bcaec51f99e5c84e1c04e1e74297 X-Gm-Message-State: ALoCoQlDVw21Y3+ilp6xHAzsIqyIPCuOv+yfhH0Z/cq7kwT6xrNvwvjvL5uAgXXRxjs7xT65smVTtVW8ptNuvDv+kVMK5KJXaihjP9KNkvMIv20JcaGDhmC3bZARzq98VVD3cwK/ufO5YPYLBxUl6hTuuEUTqR9pZgV9Zq7J9YfucWZ638tsb6Lp3YFnZ3nxG9FRRd6s4905 Cc: "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 01:21:22 -0000 --bcaec51f99e5c84e1c04e1e74297 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 19, 2013 at 6:10 PM, Cullen Jennings wrote: > > On Jul 19, 2013, at 5:56 PM, Peter Thatcher wrote: > > > > > > > > > On Fri, Jul 19, 2013 at 5:54 PM, Cullen Jennings wrote: > > > > On Jul 19, 2013, at 10:18 AM, Peter Thatcher > wrote: > > > > > > > > It's interesting that most or your list of things that needed to be > solved without SDP (simulcast, FEC, correlation of RTP streams with > MediaStreamTracks, glare) still haven't been solved for WebRTC even with > SDP, despite many months (years?) of effort. > > > > > > > Peter, with the exception of Simulcast, which of these do you think has > not been solved in SDP when not using bundle? > > > > > > > I asked about SDP, not WebRTC. The thing that is making this take a long > time is you don't want to use SDP. > > I'm not asking about SDP. I'm asking about WebRTC. It's the WebRTC API I'm concerned with. > Has FEC been defined for WebRTC? > yes, that is defined for SDP O/A > FEC still isn't defined for use with the WebRTC API. I believe it's still in the long list of things that can't be resolved until Plan A vs. Plan B is resolved. > Has glare been solved? > yes > > In the context of WebRTC, it wasn't at the last IETF. What has changed since then? > > Has mapping of RTP streams with MediaStreamTracks been resolved (with > the exception of the "unity plan" which has not yet been approved)? > This is obviously trivial if not using bundle. Any version of MSID would > work. It's only complicated by bundle > > Even without BUNDLE, it's still not clear what kind of SDP createOffer should generate for multiple tracks. (with the exception of the "unity plan" which has not yet been approved). > > > > I think the whole list I gave is still unsolved/unresolved. > I disagree. They are only unresolved because we want to add bundle and > that was a major change to RTP resulting in a bunch of work needing to be > done to see how that impacted SDP. > > It thinks there's more than just BUNDLE, but you make a good point: finishing the WebRTC API currently requires lots of major changes to SDP, which creates big delays. In fact, it's the number one things holding back the API from being done, because major changes to SDP take a really, really long time. > > > > > > > > > > --bcaec51f99e5c84e1c04e1e74297 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 19, 2013 at 6:10 PM, Cullen Jennings = <fluffy@iii.ca>= ; wrote:

On Jul 19, 2013, at 5:56 PM, Peter Thatcher <pthatcher@google.com> wrote:

>
>
>
> On Fri, Jul 19, 2013 at 5:54 PM, Cullen Jennings <fluffy@iii.ca> wrote:
>
> On Jul 19, 2013, at 10:18 AM, Peter Thatcher <pthatcher@google.com> wrote:
>
> >
> > It's interesting that most or your list of things that needed= to be solved without SDP (simulcast, FEC, correlation of RTP streams with = MediaStreamTracks, glare) still haven't been solved for WebRTC even wit= h SDP, despite many months (years?) of effort.
> >
>
> Peter, with the exception of Simulcast, which of these do you think ha= s not been solved in SDP when not using bundle?
>
>
>
I asked about SDP, not WebRTC. The thing that is making this take a l= ong time is you don't want to use SDP.


I'm not as= king about SDP. =C2=A0I'm asking about WebRTC. =C2=A0 It's the WebR= TC API I'm concerned with.

> Has FEC been defined for WebRTC?
yes, that is defined for SDP O/A

= FEC still isn't defined for use with the WebRTC API. =C2=A0I believe it= 's still in the long list of things that can't be resolved until Pl= an A vs. Plan B is resolved.

> Has glare been solved?
yes


In the context= of WebRTC, it wasn't at the last IETF. =C2=A0What has changed since th= en?
=C2=A0
> Has mapping of RTP streams with MediaStreamTracks been resolved (with = the exception of the "unity plan" which has not yet been approved= )?
This is obviously trivial if not using bundle. Any version of MSID wo= uld work. It's only complicated by bundle


Even without B= UNDLE, it's still not clear what kind of SDP createOffer should generat= e for multiple tracks. =C2=A0(with the e= xception of the "unity plan" which has not yet been approved).
=C2=A0
>
> I think the whole list I gave is still unsolved/unresolved.
I disagree. They are only unresolved because we want to add bundle an= d that was a major change to RTP resulting in a bunch of work needing to be= done to see how that impacted SDP.


It thinks there's more than just B= UNDLE, but you make a good point: =C2=A0finishing the WebRTC API currently = requires lots of major changes to SDP, which creates big delays. =C2=A0In f= act, it's the number one things holding back the API from being done, b= ecause major changes to SDP take a really, really long time.
=C2=A0


>
>
>


--bcaec51f99e5c84e1c04e1e74297-- From pthatcher@google.com Fri Jul 19 18:24:52 2013 Return-Path: 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 B3B3911E81AA for ; Fri, 19 Jul 2013 18:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.201, 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 Y0crHAPV011h for ; Fri, 19 Jul 2013 18:24:52 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC0011E8165 for ; Fri, 19 Jul 2013 18:24:51 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so5014827pbc.32 for ; Fri, 19 Jul 2013 18:24:51 -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=GuM5rsKLA9hByJolqiQPRe96K/w13VCTHyuBEXdKlBY=; b=F+P3KBpmkQnbxkOuvW4UFX1kNFKHtws5s89n8wEy8to7zAYVGCNMTYmpQ2ccyaBWpO icMv0+8ml53NfUMmhpZ6KdsQQ/WY0wqLlbz8JwCHkEqlYYh+VDyXvxj2xByBFVL21Vhp VVO1ZGfTv9idKHJxFtcNy1wJ9EMFzzBicQbjnYx/P79cxNW+FcVK1vdQWbNaaUUckhAp 9FJzB2Q3yWbTwMMOOmz1bFFLjrPE2UKlOFjEWvHNlvbM6DJvG4qbgsAe2rjx5prHyDys vGMsKt59cRKCY3bzids7pZd1trbduMlsFqS5BPZtdXcRRP7iz+zXyz7CTSx8d7tpyn9V 6VCw== 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=GuM5rsKLA9hByJolqiQPRe96K/w13VCTHyuBEXdKlBY=; b=EJnEnmZEeXmfa/pZ/W5T0vjFcoO9ltuf/grmTr0YEqIFUHme+vkgbRyCRdzozPlnsY rCiMgt+PTzUsJXKtYqGHCS8xUfZTIFNpLbCGtxIr0HPxOqKTeOAffXbfZ0fKjsAKLkyl dwG4xZ/8VY+bXPp5naXdU5iZkVNcVRzdb/TAhGnAiUwdewqfXOHzPbmf5Kq9TwuGumuM p1mo2+1rV1JsBRyZ0PMzIK/v/br4d/77+q6utJ8Lp6JYUgSy9FMmrZ5eOLaRrHop0Y1T 4xluJ3ygdmdkOKm+sxabJyiAbhhcdFVzCLjUBz84rGlgFqg8miNTSeJTvXH5JMuqkgiW iDTw== X-Received: by 10.66.228.72 with SMTP id sg8mr20893670pac.45.1374283491448; Fri, 19 Jul 2013 18:24:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 18:24:11 -0700 (PDT) In-Reply-To: <0D2B47D9-25BF-40C1-AC41-DF65093A6B94@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> <0D2B47D9-25BF-40C1-AC41-DF65093A6B94@iii.ca> From: Peter Thatcher Date: Fri, 19 Jul 2013 18:24:11 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7b111cff5436cd04e1e74fe6 X-Gm-Message-State: ALoCoQm/bJRcY3p8wnT4F32TIny5ZKwO/2bp2icp1KKLM9UoXhBacI9Zhi6U45nepG0CpQse0Ubfi/VnRD5qr6hlWGnAMRTa6+vHIi7ms27B1pQmvPmIRMPP19GQlomk2dRc7po1w2s1bwi+BEZ5PpYmXiB+LF18YXaP0sjdhOHRfTgz1rfdeSbjjUtagr+fUzyEp3JUWTZn Cc: "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 01:24:52 -0000 --047d7b111cff5436cd04e1e74fe6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You're surprised that the first web developers that try out WebRTC and have feedback have experience with SIP and VoIP? We shouldn't find that surprising, nor should we discount their feedback because of it. In any case, it's the best data we've got so far. I made an effort to some data because no one else had. If you would like to make an effort to get better feedback, I'd more than welcome it. In fact, I'd say you ought not to have waited for me to do it. On Fri, Jul 19, 2013 at 6:20 PM, Cullen Jennings wrote: > > Thanks, > > I will note that over half of that very small sample set is folks that > have been long termed involved in SIP and VoIP so, uh, might not be a > representative sample of type of people you are portraying it as. > > > On Jul 19, 2013, at 7:51 AM, Peter Thatcher wrote: > > > Here you go: > > > > > > > > > > On Fri, Jul 19, 2013 at 7:00 AM, Cullen Jennings wrote: > > Can someone please email a full copy of the spreadsheet to the list so > it is in the archives - thanks > > > > On Jul 9, 2013, at 3:18 AM, I=C3=B1aki Baz Castillo wro= te: > > > > > 2013/7/9 Stefan H=C3=A5kansson LK : > > >> I want to be very clear and careful on what I say. So I am repeating= : > > >> > > >> * My comment that I think Eric is right in that there is consensus o= n > > >> providing APIs that allow most use-cases to be met without SDP > mangling > > >> is meant only in that context: SDP O/A is kept (and PeerConnection > more > > >> or less as is and so on). > > > > > > Hi Stefan, > > > > > > You insist that "there is consensus on keeping SDP O/A but providing = a > > > better API". Given current discussions IMHO it is clear there is not > > > such a consensus (not at all). Or may be you are just talking about > > > two years ago in some IETF meeting (if so I'm sorry). > > > > > > Please review the results in > > > > https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdH= lZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1 > > > > > > Bad for advanced stuff: 94% > > > OK for 1.0: 40% > > > > > > IMHO such a result indicates all but "let's keep SDP O/A and improve = a > > > bit the API" (I mean now, in July 2013). > > > > > > > > > Best regards. > > > > > > > > > > > > -- > > > I=C3=B1aki Baz Castillo > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > Inputs.csv> > > --047d7b111cff5436cd04e1e74fe6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You're surprised that the first web developers th= at try out WebRTC and have feedback have experience with SIP and VoIP? =C2= =A0We shouldn't find that surprising, nor should we discount their feed= back because of it.

In any case, it's the best data we've got so far. = =C2=A0I made an effort to some data because no one else had. =C2=A0If you w= ould like to make an effort to get better feedback, I'd more than welco= me it. =C2=A0In fact, I'd say you ought not to have waited for me to do= it.


On Fri, Jul 1= 9, 2013 at 6:20 PM, Cullen Jennings <fluffy@iii.ca> wrote:

Thanks,

I will note that over half of that very small sample set is folks that have= been long termed involved in SIP and VoIP so, uh, might not be a represent= ative sample of type of people you are portraying it as.


On Jul 19, 2013, at 7:51 AM, Peter Thatcher <pthatcher@google.com> wrote:

> Here you go:
>
>
>
>
> On Fri, Jul 19, 2013 at 7:00 AM, Cullen Jennings <fluffy@iii.ca> wrote:
> Can someone please email a full copy of the spreadsheet to the list so= it is in the archives - thanks
>
> On Jul 9, 2013, at 3:18 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
>
> > 2013/7/9 Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com>:
> >> I want to be very clear and careful on what I say. So I am re= peating:
> >>
> >> * My comment that I think Eric is right in that there is cons= ensus on
> >> providing APIs that allow most use-cases to be met without SD= P mangling
> >> is meant only in that context: SDP O/A is kept (and PeerConne= ction more
> >> or less as is and so on).
> >
> > Hi Stefan,
> >
> > You insist that "there is consensus on keeping SDP O/A but p= roviding a
> > better API". Given current discussions IMHO it is clear ther= e is not
> > such a consensus (not at all). Or may be you are just talking abo= ut
> > two years ago in some IETF meeting (if so I'm sorry).
> >
> > Please review the results in
> > https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=3D0AuaKXw3SkHMSdHl= ZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=3D1
> >
> > =C2=A0Bad for advanced stuff: 94%
> > =C2=A0OK for 1.0: 40%
> >
> > IMHO such a result indicates all but "let's keep SDP O/A= and improve a
> > bit the API" (I mean now, in July 2013).
> >
> >
> > Best regards.
> >
> >
> >
> > --
> > I=C3=B1aki Baz Castillo
> > <ibc@aliax.net>
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> <Input from JS Developers on their experience with the = WebRTC API - Inputs.csv>


--047d7b111cff5436cd04e1e74fe6-- From fluffy@iii.ca Fri Jul 19 18:24:58 2013 Return-Path: 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 8C9FB21E80D4 for ; Fri, 19 Jul 2013 18:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, 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 TUo32ZTMPQws for ; Fri, 19 Jul 2013 18:24:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BAFE311E8165 for ; Fri, 19 Jul 2013 18:24:52 -0700 (PDT) Received: from sjc-vpn5-843.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 66B0622E1F4; Fri, 19 Jul 2013 21:24:45 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Fri, 19 Jul 2013 18:24:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C837643-5DB1-4192-8DA3-6D999E867E77@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1508) Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 01:24:58 -0000 On Jul 19, 2013, at 8:03 AM, I=F1aki Baz Castillo wrote: > 2013/7/19 Cullen Jennings : >> Folks wanted to sort out how mindless works fist before getting to = theses smaller details >=20 > Hi Cullen, >=20 > All these "smaller details" are in fact issues and problems we don't > need. Issues not needed at all in WebRTC, issues that WebRTC > developers and vendors should NOT care about. If those "smaller > details" do exist is due the mandate of SDP. And all the time the WG > (or WGs) will spent "fixing/defining" them is just wasted time, since > nothing useful is being done for WebRTC by "defining" those "minor > details". >=20 > Regards. >=20 Well lets prioritize fixing them. Which ones are causing = interoperability problems between browsers?=20 From fluffy@iii.ca Fri Jul 19 18:47:45 2013 Return-Path: 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 15CBC11E81AA for ; Fri, 19 Jul 2013 18:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6] 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 nDqqsTI9sjo5 for ; Fri, 19 Jul 2013 18:47:37 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0630521F9FFC for ; Fri, 19 Jul 2013 18:47:36 -0700 (PDT) Received: from sjc-vpn5-843.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B7C5422E1F3; Fri, 19 Jul 2013 21:47:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Fri, 19 Jul 2013 18:47:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> To: Peter Thatcher X-Mailer: Apple Mail (2.1508) Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 01:47:45 -0000 Well that was clearly one or my more mindless emails=20 What I mean to say was something along lines of=20 Folks want to sort out the multiplexing / bundle stuff first.=20 So let me suggest that folks read section 6 of the JSEP draft and see if = they can answer most of of the questions below. I'm not saying that = section 6 is right, in fact I think some of it is wrong. But at least = act like you have read it. On Jul 19, 2013, at 7:49 AM, Peter Thatcher = wrote: > "mindless works fist"? There's a deep meaning there, but I'm still = trying to figure it out... >=20 >=20 > On Fri, Jul 19, 2013 at 7:04 AM, Cullen Jennings = wrote: > Folks wanted to sort out how mindless works fist before getting to = theses smaller details but in general I think progress is being made on = all of these >=20 > On Jul 17, 2013, at 2:58 PM, "Matthew Kaufman (SKYPE)" = wrote: >=20 > > Bernard Aboba: > >> > >> The problem was that we never defined what mangling browsers had to > >> support. Given all the SDP specs that is actually a huge work item. > > > > > > This is exactly what my slides that weren't presented last November = started to touch upon. It only takes a few minutes with RFC3264 and its = references to start documenting cases that are clearly "valid SDP = offer/answer" and yet for which I cannot for the life of me figure out = what a browser should do if they're presented. > > > > Just off the top of my head: > > > > Can I... > > - Change the t=3D line to be something other than t=3D0 0? Current JSEP draft says the browser does not need to allow that to be = changed. > > - Change the rtpmap associations before calling setLocal? you can remove or reorder > > - Change a=3Dsendrecv to a=3Drecvonly before calling setLocal? Current JSEP draft says that is done with constraints > > - What do you do when you see a=3Dcontent:sl ? not in current spec but you can find dissection on list about making = sure that is available to API=20 > > - What if someone adds an r=3D or p=3D or e=3D? Current JSEP draft says the browser does not need to allow that=20 > - What is the RFC that describes a=3Dgroup:BUNDLE (as seen in some = browser implementations)? Uh, I'll leave that as an exercise to the readers. Try hard and see if = you can find it.=20 > > - Can I remove a=3Dgroup:BUNDLE (or add it) before calling setLocal? Current JSEP draft says that is done with constraints > > - How about removing a=3Drtcp-mux? Current JSEP draft says that is done with constraints > > - Should I do something special at my end if you set = a=3Dice-options:google-ice ? Do whatever the ice spec say=20 > > - If you put a=3Dssrc lines in there, can I change the ssrc before = passing it back to setLocal? Current JSEP draft says the browser does not need to allow that to be = changed. > > - Can I delete the a=3Dssrc lines? Current JSEP draft says the browser does not need to allow that to be = changed. > > - Is a=3Drtcp:1 IN IP4 0.0.0.0 valid or not? Why would a browser want to generate that? > > - What about 0.0.0.0 in the o=3D line? Why would a browser want to generate that? > > - If I get a bunch of a=3Dcandidate lines, can I swap them around to = change the priority before calling setLocal? Current JSEP draft says the browser does not need to allow that to be = changed. > > - What if someone claims SAVP instead of SAVPF but gives me rtcp = info? We need to add text to explicitly cover that. You can find text on what = I think we should do for this in=20 draft-jennings-rtcweb-plan-01 > > > > At the *very least* for each and every line that comes from = createOffer and createAnswer you must be able to answer the following: > > - Can I delete it? > > - Duplicate it? > > - Change it? > > - If not, how are violation handled? (Both when passed to another = browser at the far end and when these modifications happen before = calling setLocal) > > - And can I add additional valid SDP to what came from createOffer = or createAnswer and pass it back to setLocal or not? > > > > We appear to be nowhere near a document which explains the answers = to these questions, certainly not in the W3C WG, and not in any IETF RFC = or draft I can locate. draft-ietf-rtcweb-jsep-03 has tried to address some of these. I = certainly don't claim it is perfect but if people have use cases that = suggest a change to this, love to get text on what it should be.=20 Mathew has been very clear along the way of "we need to define X to have = an interoperable system" and for most values of X he has proposed, I = agree with him. However, I think we just need to do that and that it = actually won't be much work once we get the framework in place to deal = with thinks like how many ports is the RTP using and how many m-lines = does the SDP have.=20 > > > > Matthew Kaufman > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From fluffy@iii.ca Fri Jul 19 18:52:51 2013 Return-Path: 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 4440411E81CD for ; Fri, 19 Jul 2013 18:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 zt8iZ-eLk1up for ; Fri, 19 Jul 2013 18:52:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA3211E8191 for ; Fri, 19 Jul 2013 18:52:45 -0700 (PDT) Received: from sjc-vpn5-843.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9139022E1F4; Fri, 19 Jul 2013 21:52:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Fri, 19 Jul 2013 18:52:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CFEEBBF-DD98-4EDA-9595-F4E3ACB8A94F@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> <0D2B47D9-25BF-40C1-AC41-DF65093A6B94@iii.ca > To: Peter Thatcher X-Mailer: Apple Mail (2.1508) Cc: rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 01:52:51 -0000 On Jul 19, 2013, at 6:24 PM, Peter Thatcher = wrote: > You're surprised that the first web developers that try out WebRTC and = have feedback have experience with SIP and VoIP? We shouldn't find that = surprising, nor should we discount their feedback because of it. I was not saying that feedback from folks like Bernard Aboba was not = useful, of course it can be. I was just noting the sample set.=20= From pthatcher@google.com Fri Jul 19 18:56:52 2013 Return-Path: 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 43F1F11E81CC for ; Fri, 19 Jul 2013 18:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, 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 SSJFMuuulgxL for ; Fri, 19 Jul 2013 18:56:51 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 468E411E81CD for ; Fri, 19 Jul 2013 18:56:50 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so4887906pdi.27 for ; Fri, 19 Jul 2013 18:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=COSRj/ZGEqWZIx3M6cq53TF0+P1lYlIOZMH23L8fagc=; b=auCDX88ifDCb1Vi0mw2bG/uI/McWoId4AD8GEe3HDv/L+2LRVXXbuaCzOjhfNzL5ad 7Y7L+iJvK56iMzLQ7eZyT+RgelveP8HKZDGcrLJEi5QMGBsAH5SOZR2OISrYO/AageyT ZeXbZcuiJOqkSJ+zdSYFg00ZYzH+yczsoD6ZCu/gRaSpdN4J6cofNyCRh2V3ViJsbzwt 36mqA83yv1PZ641acdyOW8j53S/gSD26XfWuSG0ohdopv2J1rMt6A1mVLRaCfi3cmzyn 5frKxSm4if8hauM+Hr3O2l/lV1ai6Hpl4gqRTsNq/2os3DI+FExoAK1d0rUQ8zr9IouM FNJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=COSRj/ZGEqWZIx3M6cq53TF0+P1lYlIOZMH23L8fagc=; b=XRzZSYFkq8s9rWwguqEJ1IvORGYoufPqKVEQdA8At/q21oseNjpUqt+JueDWP/oJ0N 388f2vDjsXgh+7yYQWU4T28b+b/VK8csY8orTGZUDBX0KYbgK6UeceVSwGcP5bwCNP9c eAoan2yMaxR5CGw8VwCcYLQKo578KsErkBuda8fgcAeS4mDaqkx3jRCsPcMGhuZG0qw+ kMmmh8AehcyKwW2EudZ9TymLrD87BpL1Chm4t7RQW+BSchnnr7tAIf34HO5z2TREjr+F p5r20tpPlo775BEiLMuiFq7Z0yrzF7GdcWjY69bnRCxUCUXPM9ZJc/AC6eiZCSRG7+lG U+/A== MIME-Version: 1.0 X-Received: by 10.68.213.5 with SMTP id no5mr19868671pbc.185.1374285410470; Fri, 19 Jul 2013 18:56:50 -0700 (PDT) Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 18:56:50 -0700 (PDT) Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 18:56:50 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> Date: Fri, 19 Jul 2013 18:56:50 -0700 Message-ID: From: Peter Thatcher To: Cullen Jennings Content-Type: multipart/alternative; boundary=e89a8fb20834b6328c04e1e7c194 X-Gm-Message-State: ALoCoQnmjpPpsu+6BVHeonNLKUDqS2pFj+8xELoTXW2aGWyeFizvStCy7gwuRZ3uEEsoNoJ07w1K63vvCdSz51NzrcD4uolsCUgXHdZjpyVQcEXkagkR6GFiZvx5rT46cnyIsOIDIFpTRLaKo6d8ldJh1Ixqt7OYJxxbUbEGKzxlxBMkfKhelWKl3QYMa+vnRkCk2ruqoHYr 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 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 01:56:52 -0000 --e89a8fb20834b6328c04e1e7c194 Content-Type: text/plain; charset=UTF-8 On Jul 19, 2013 6:47 PM, "Cullen Jennings" wrote: > > > Well that was clearly one or my more mindless emails > > What I mean to say was something along lines of > > Folks want to sort out the multiplexing / bundle stuff first. > > So let me suggest that folks read section 6 of the JSEP draft and see if they can answer most of of the questions below. I'm not saying that section 6 is right, in fact I think some of it is wrong. But at least act like you have read it. > > > On Jul 19, 2013, at 7:49 AM, Peter Thatcher wrote: > > > "mindless works fist"? There's a deep meaning there, but I'm still trying to figure it out... > > > > > > On Fri, Jul 19, 2013 at 7:04 AM, Cullen Jennings wrote: > > Folks wanted to sort out how mindless works fist before getting to theses smaller details but in general I think progress is being made on all of these > > > > On Jul 17, 2013, at 2:58 PM, "Matthew Kaufman (SKYPE)" < matthew.kaufman@skype.net> wrote: > > > > > Bernard Aboba: > > >> > > >> The problem was that we never defined what mangling browsers had to > > >> support. Given all the SDP specs that is actually a huge work item. > > > > > > > > > This is exactly what my slides that weren't presented last November started to touch upon. It only takes a few minutes with RFC3264 and its references to start documenting cases that are clearly "valid SDP offer/answer" and yet for which I cannot for the life of me figure out what a browser should do if they're presented. > > > > > > Just off the top of my head: > > > > > > Can I... > > > - Change the t= line to be something other than t=0 0? > > Current JSEP draft says the browser does not need to allow that to be changed. > > > > - Change the rtpmap associations before calling setLocal? > > you can remove or reorder > > > > - Change a=sendrecv to a=recvonly before calling setLocal? > > Current JSEP draft says that is done with constraints > > > > - What do you do when you see a=content:sl ? > > not in current spec but you can find dissection on list about making sure that is available to API > > > > - What if someone adds an r= or p= or e=? > > Current JSEP draft says the browser does not need to allow that > > > - What is the RFC that describes a=group:BUNDLE (as seen in some browser implementations)? > > Uh, I'll leave that as an exercise to the readers. Try hard and see if you can find it. > > > > > - Can I remove a=group:BUNDLE (or add it) before calling setLocal? > > Current JSEP draft says that is done with constraints > > > > - How about removing a=rtcp-mux? > > Current JSEP draft says that is done with constraints > > > > > - Should I do something special at my end if you set a=ice-options:google-ice ? > > Do whatever the ice spec say > > > > - If you put a=ssrc lines in there, can I change the ssrc before passing it back to setLocal? > Current JSEP draft says the browser does not need to allow that to be changed. > > > > > - Can I delete the a=ssrc lines? > > Current JSEP draft says the browser does not need to allow that to be changed. > > > > > - Is a=rtcp:1 IN IP4 0.0.0.0 valid or not? > > Why would a browser want to generate that? > > > > - What about 0.0.0.0 in the o= line? > > Why would a browser want to generate that? > > > > - If I get a bunch of a=candidate lines, can I swap them around to change the priority before calling setLocal? > > Current JSEP draft says the browser does not need to allow that to be changed. > > > > - What if someone claims SAVP instead of SAVPF but gives me rtcp info? > > We need to add text to explicitly cover that. You can find text on what I think we should do for this in > draft-jennings-rtcweb-plan-01 > > > > > > > > At the *very least* for each and every line that comes from createOffer and createAnswer you must be able to answer the following: > > > - Can I delete it? > > > - Duplicate it? > > > - Change it? > > > - If not, how are violation handled? (Both when passed to another browser at the far end and when these modifications happen before calling setLocal) > > > - And can I add additional valid SDP to what came from createOffer or createAnswer and pass it back to setLocal or not? > > > > > > We appear to be nowhere near a document which explains the answers to these questions, certainly not in the W3C WG, and not in any IETF RFC or draft I can locate. > > draft-ietf-rtcweb-jsep-03 has tried to address some of these. I certainly don't claim it is perfect but if people have use cases that suggest a change to this, love to get text on what it should be. > > Mathew has been very clear along the way of "we need to define X to have an interoperable system" and for most values of X he has proposed, I agree with him. However, I think we just need to do that and that it actually won't be much work once we get the framework in place to deal with thinks like how many ports is the RTP using and how many m-lines does the SDP have. FYI, Adam today said "we're nowhere close" and now you're saying it "won't be much work". > > > > > > > Matthew Kaufman > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > --e89a8fb20834b6328c04e1e7c194 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 19, 2013 6:47 PM, "Cullen Jennings" <fluffy@iii.ca> wrote:
>
>
> Well that was clearly one or my more mindless emails
>
> What I mean to say was something along lines of
>
> Folks want to sort out the multiplexing / bundle stuff first.
>
> So let me suggest that folks read section 6 of the JSEP draft and see = if they can answer most of of the questions below. I'm not saying that = section 6 is right, in fact I think some of it is wrong. But at least act l= ike you have read it.
>
>
> On Jul 19, 2013, at 7:49 AM, Peter Thatcher <pthatcher@google.com> wrote:
>
> > "mindless works fist"? =C2=A0There's a deep meaning= there, but I'm still trying to figure it out...
> >
> >
> > On Fri, Jul 19, 2013 at 7:04 AM, Cullen Jennings <fluffy@iii.ca> wrote:
> > Folks wanted to sort out how mindless works fist before getting t= o theses smaller details but in general I think progress is being made on a= ll of these
> >
> > On Jul 17, 2013, at 2:58 PM, "Matthew Kaufman (SKYPE)" = <matthew.kaufman@skype.net<= /a>> wrote:
> >
> > > Bernard Aboba:
> > >>
> > >> The problem was that we never defined what mangling brow= sers had to
> > >> support. Given all the SDP specs that is actually a huge= work item.
> > >
> > >
> > > This is exactly what my slides that weren't presented la= st November started to touch upon. It only takes a few minutes with RFC3264= and its references to start documenting cases that are clearly "valid= SDP offer/answer" and yet for which I cannot for the life of me figur= e out what a browser should do if they're presented.
> > >
> > > Just off the top of my head:
> > >
> > > Can I...
> > > - Change the t=3D line to be something other than t=3D0 0? >
> Current JSEP draft says the browser does not need to allow that to be = changed.
>
> > > - Change the rtpmap associations before calling setLocal? >
> you can remove or reorder
>
> > > - Change a=3Dsendrecv to a=3Drecvonly before calling setLoca= l?
>
> Current JSEP draft says that is done with constraints
>
> > > - What do you do when you see a=3Dcontent:sl ?
>
> not in current spec but you can find dissection on list about making s= ure that is available to API
>
> > > - What if someone adds an r=3D or p=3D or e=3D?
>
> Current JSEP draft says the browser does not need to allow that
>
> > - What is the RFC that describes a=3Dgroup:BUNDLE (as seen in som= e browser implementations)?
>
> Uh, I'll leave that as an exercise to the readers. Try hard and se= e if you can find it.
>
>
> > > - Can I remove a=3Dgroup:BUNDLE (or add it) before calling s= etLocal?
>
> Current JSEP draft says that is done with constraints
>
> > > - How about removing a=3Drtcp-mux?
>
> Current JSEP draft says that is done with constraints
>
>
> > > - Should I do something special at my end if you set a=3Dice= -options:google-ice ?
>
> Do whatever the ice spec say
>
> > > - If you put a=3Dssrc lines in there, can I change the ssrc = before passing it back to setLocal?
> Current JSEP draft says the browser does not need to allow that to be = changed.
>
>
> > > - Can I delete the a=3Dssrc lines?
>
> Current JSEP draft says the browser does not need to allow that to be = changed.
>
>
> > > - Is a=3Drtcp:1 IN IP4 0.0.0.0 valid or not?
>
> Why would a browser want to generate that?
>
> > > - What about 0.0.0.0 in the o=3D line?
>
> Why would a browser want to generate that?
>
> > > - If I get a bunch of a=3Dcandidate lines, can I swap them a= round to change the priority before calling setLocal?
>
> Current JSEP draft says the browser does not need to allow that to be = changed.
>
> > > - What if someone claims SAVP instead of SAVPF but gives me = rtcp info?
>
> We need to add text to explicitly cover that. You can find text on wha= t I think we should do for this in
> draft-jennings-rtcweb-plan-01
>
>
> > >
> > > At the *very least* for each and every line that comes from = createOffer and createAnswer you must be able to answer the following:
> > > - Can I delete it?
> > > - Duplicate it?
> > > - Change it?
> > > - If not, how are violation handled? (Both when passed to an= other browser at the far end and when these modifications happen before cal= ling setLocal)
> > > - And can I add additional valid SDP to what came from creat= eOffer or createAnswer and pass it back to setLocal or not?
> > >
> > > We appear to be nowhere near a document which explains the a= nswers to these questions, certainly not in the W3C WG, and not in any IETF= RFC or draft I can locate.
>
> draft-ietf-rtcweb-jsep-03 has tried to address some of these. I certai= nly don't claim it is perfect but if people have use cases that suggest= a change to this, love to get text on what it should be.
>
> Mathew has been very clear along the way of "we need to define X = to have an interoperable system" and for most values of X he has propo= sed, I agree with him. However, I think we just need to do that and that it= actually won't be much work once we get the framework in place to deal= with thinks like how many ports is the RTP using and how many m-lines does= the SDP have.

FYI, Adam today said "we're nowhere close" and= now you're saying it "won't be much work".=C2=A0

>
> > >
> > > Matthew Kaufman
> > >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > htt= ps://www.ietf.org/mailman/listinfo/rtcweb
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb
> >
>

--e89a8fb20834b6328c04e1e7c194-- From pthatcher@google.com Fri Jul 19 19:10:28 2013 Return-Path: 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 63D2421E8056 for ; Fri, 19 Jul 2013 19:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.212, 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 6vG+-OrT8U65 for ; Fri, 19 Jul 2013 19:10:28 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id EC90211E81CC for ; Fri, 19 Jul 2013 19:10:27 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so5039959pbb.19 for ; Fri, 19 Jul 2013 19:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q+Cs3e+DYY4tQb2ptbSrUG3RkdkWtyH3M9zpmrvC7tU=; b=Bfzd6EE1RlAozONLt9diklc6TplfwtxnImK92Gnq9LcGgkpVAPXmdwLi01z+91D7eq cb1VlkV/cTMuG3q5/BUsys/j/LiOVj+c8z97skbIW+FCPaMQYzf5mIf34gpTKcpswMih a1Q8hdtLo3jDTwWI6AkpRFzE1i17dYNqaISzTbEJnOiL5qoGeeZbMElApRJs20pqqdsT +oRr3p70IGfR1qP7uWRTbePZ/F/4bbTrfBxTBGxvoLFXRZDTsQFNekDCZyE/y+qoEWZ9 Xp3xjgikDVqJ5zrf9pF0Hqzl5DkMxnchyzkBLKCdQtecgXTTbAjC0DlXBQsye2r6ZrVA 16lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=q+Cs3e+DYY4tQb2ptbSrUG3RkdkWtyH3M9zpmrvC7tU=; b=D48ufgeCetruUhm5eO0P4u8+9K42EeNuQaIgLd4iLzE/85z822SFu4jh+rXrZY0GKw ZRG/xR6w7mM7tHL0GueU3OYFaLoKij0Alq/AkHSjDHvO7KunBSkC07wLzaP81OCgC5IL 8UcvxXbS6+ljS5vLCaUZDrQ81jX+PywYsG9WLHVGYcQHcyoeQWNpUzbLXJfIvmTEfEU4 vWQ6MWqce1u2DZQDFnz60mTCoDk0cfPxgSU80UIjJ5/WdaOMt08kZkPtaeNC2qRJBWSu TlnCagjpfvvpBaA3xTqBfUCfZ3NdanDYQh3PRhgOOUVCdZdOJHP9yaNW0GkU4x2gqvg6 EbkA== MIME-Version: 1.0 X-Received: by 10.68.104.196 with SMTP id gg4mr20310817pbb.25.1374286226474; Fri, 19 Jul 2013 19:10:26 -0700 (PDT) Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 19:10:26 -0700 (PDT) Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 19:10:26 -0700 (PDT) In-Reply-To: <1CFEEBBF-DD98-4EDA-9595-F4E3ACB8A94F@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> <1CFEEBBF-DD98-4EDA-9595-F4E3ACB8A94F@iii.ca> Date: Fri, 19 Jul 2013 19:10:26 -0700 Message-ID: From: Peter Thatcher To: Cullen Jennings Content-Type: multipart/alternative; boundary=047d7b6705b95989f604e1e7f209 X-Gm-Message-State: ALoCoQnRtIDJAh/ScSeeKw8ymyFae56FGpaAJIr2m9LzRgCjc5E6BXG8hXt1DRSYQ5Zh+OVO6B+/erZlWOK294I2QTgaUwB4L5f8hSR2gPeaeI1Qi/+3scLo3hicCu8Yy40SV9sCAZKILV0YT5pZ8Lqpx5P44Q7Wvvvthg76AuOx3z+4/HsBDgH+JsCWL8vQX1y8RmLYUC93 Cc: rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 02:10:28 -0000 --047d7b6705b95989f604e1e7f209 Content-Type: text/plain; charset=UTF-8 Like I said when I first sent the summary, anyone is welcome to make a different summary from the raw data, or collect their own data. I haven't been around long enough to know how to categorize people and whose input is considered valuable and whose isn't, so I ignorantly gave everyone equal weight. So if you'd like, you can filter out Bernard and recalculate. On Jul 19, 2013 6:52 PM, "Cullen Jennings" wrote: > > On Jul 19, 2013, at 6:24 PM, Peter Thatcher wrote: > > > You're surprised that the first web developers that try out WebRTC and > have feedback have experience with SIP and VoIP? We shouldn't find that > surprising, nor should we discount their feedback because of it. > > I was not saying that feedback from folks like Bernard Aboba was not > useful, of course it can be. I was just noting the sample set. --047d7b6705b95989f604e1e7f209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Like I said when I first sent the summary, anyone is welcome= to make a different summary from the raw data, or collect their own data.= =C2=A0 I haven't been around long enough to know how to categorize peop= le and whose input is considered valuable and whose isn't, so I ignoran= tly gave everyone equal weight.=C2=A0 So if you'd like, you can filter = out=C2=A0 Bernard and recalculate.

On Jul 19, 2013 6:52 PM, "Cullen Jennings&q= uot; <fluffy@iii.ca> wrote:

On Jul 19, 2013, at 6:24 PM, Peter Thatcher <pthatcher@google.com> wrote:

> You're surprised that the first web developers that try out WebRTC= and have feedback have experience with SIP and VoIP? =C2=A0We shouldn'= t find that surprising, nor should we discount their feedback because of it= .

I was not saying that feedback from folks like Bernard Aboba was not useful= , of course it can be. I was just noting the sample set.
--047d7b6705b95989f604e1e7f209-- From matthew.kaufman@skype.net Fri Jul 19 20:17:13 2013 Return-Path: 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 ; 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 ; 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 ; 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)" To: Cullen Jennings , Martin Thomson 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: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.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" , "" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > wrote: >=20 > > Negotiation is a hole. A vast, soul-sucking, waste of time. >=20 > That's might be closer to true when you control both ends, like Skype. >=20 > 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 videoconferenci= ng system, then that's fine. If you think that the second vendor is going to get the first vendor to shi= p 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 conta= ins a complete JavaScript implementation, there's no reason why it should b= e. The first vendor should provide the JS APIs that are necessary for the s= econd 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 e= lse is going to be. Matthew Kaufman From robin@hookflash.com Fri Jul 19 20:17:58 2013 Return-Path: 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 8C48721E80C6 for ; Fri, 19 Jul 2013 20:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 KDuRLKmlnZcw for ; Fri, 19 Jul 2013 20:17:53 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 45E4721F9D75 for ; Fri, 19 Jul 2013 20:17:53 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so10933355iea.18 for ; Fri, 19 Jul 2013 20:17:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=gg0aENs2YMJaIClN2K45rlz+F9qP5mZIvhDwhloUBDM=; b=Jx+115sG0MX6FJbRxkzqoLusND2vPlHj2vFFaqB6hF8CDpWsbSGXfdBTBvS8LjlSvh BHPsCIYriectCCUddN3q4su9QqDV6vaEt8XRkg1GWtIA0JnlcEIFPrbsYTvwFeyVLXBD 2xX5BdY/ji3jSRUepDVwXr/NiP5be8EOUmNUHsb9ssoxHR9i99gXtYDihczTkMXTViwQ y3yxg1G1Og3tfCzcFVrLRssCUXDBynIeQv1rxNe1Kq4qAiYjgWeT6faHl5f/fHTNubo1 RJiq8xgUnXp2bdkpnJ0Sx8Ts2qFArOdH3C20QKQejS9UrLx6dMPipHBxtsKjW00dJ23f DFmQ== X-Received: by 10.50.130.113 with SMTP id od17mr4760391igb.10.1374290272858; Fri, 19 Jul 2013 20:17:52 -0700 (PDT) Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id nm17sm42936580igb.5.2013.07.19.20.17.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 20:17:51 -0700 (PDT) Message-ID: <51EA015B.2030509@hookflash.com> Date: Fri, 19 Jul 2013 23:17:47 -0400 From: Robin Raymond User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Cullen Jennings References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <3C837643-5DB1-4192-8DA3-6D999E867E77@iii.ca> In-Reply-To: <3C837643-5DB1-4192-8DA3-6D999E867E77@iii.ca> Content-Type: multipart/alternative; boundary="------------070004090408090607010201" X-Gm-Message-State: ALoCoQk9278mpEp65BAPGgCLYuskFdAnnAqL6w/t6fPjNhKdwqBS5uoPYe/8hxyqRS2KW7MOmk98 Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 03:17:58 -0000 This is a multi-part message in MIME format. --------------070004090408090607010201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Is WebRTC exclusively targeting browser interoperability ? I'm not trying to nitpick, but this is a vital point of issue. If yes, then why do we need to carry so much legacy SDP stuff to achieve basic sending of media between browsers? Seems like an incredible designoverkill to me. It's much easier to define a minimal feature set with a wire protocol that can achieve basic media between browsers. You could define "SDP-light" and that would be sufficient. If no, then why isn't JavaScript the entity generating the SDPs rather than the browser binaries? If the browsers aren't the end-all-be-all for interoperability, then all those SDPs have work not just between browsers, but untold numbers of SIP devices, servers, gateways, relays, desktop applications and mobile devices. Either all of those devices have to become equally capable of handling every WebRTC SDP produced from every browser, every version, working around every format difference, as every other device on the planet -- or -- we'll have to extract the SDP information using JS libraries and signal a format strictly compatible to our network environment. Personally, I think most will choose the latter in practice. Even SIP people using SDP will end up extracting the browser's SDP and recreate their own SDP instead. Given how tough it is for two browser vendors (who even have access to each other's source code) to get this SDP negotiation right, I'm extremely concerned about an entire planet of devices getting this stuff right. The trouble isn't that SDP isn't expressive enough or it's too ugly a format, it's that it's too expressive (okay, and it's ugly too). The trouble isn't that it's easy to negotiate O/A only for simple cases, it's that when we end up having to signal this stuff in "our own way", we'll be fighting with an O/A state negotiation machine instead of controlling the RTP engine directly with knobs and dials. As a developer, I want: 1) to control what the RTP engine does on the wire (to ensure compatibility between devices); 2) strict, well defined, easy-to-understand API contracts that do not change, and are only extended in well defined ways; 3) knobs and dials to control the exposed capabilities, and _not_ a negotiation machine to not fight where I can only indirectly "do what I want"; 4) predictable outputs, i.e. not having random extensions or odd differences in the middle some blob format show up from version-to-version, and from browser-to-browser; I do not believe we can address these by tweaking the SDP format, or defining SDP better, or making wrappers for SDP. The problem is fundamentally SDP O/A as the mandated. -Robin > Cullen Jennings > 19 July, 2013 9:24 PM > > > Well lets prioritize fixing them. Which ones are causing > interoperability problems between browsers? --------------070004090408090607010201 Content-Type: multipart/related; boundary="------------060002030301030201000606" --------------060002030301030201000606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Is WebRTC exclusively targeting browser interoperability ? I'm not trying to nitpick, but this is a vital point of issue.

If yes, then why do we need to carry so much legacy SDP stuff to achieve basic sending of media between browsers? Seems like an incredible design overkill to me. It's much easier to define a minimal feature set with a wire protocol that can achieve basic media between browsers. You could define "SDP-light" and that would be sufficient.

If no, then why isn't JavaScript the entity generating the SDPs rather than the browser binaries?

If the browsers aren't the end-all-be-all for interoperability, then all those SDPs have work not just between browsers, but untold numbers of SIP devices, servers, gateways, relays, desktop applications and mobile devices. Either all of those devices have to become equally capable of handling every WebRTC SDP produced from every browser, every version, working around every format difference, as every other device on the planet -- or -- we'll have to extract the SDP information using JS libraries and signal a format strictly compatible to our network environment. Personally, I think most will choose the latter in practice. Even SIP people using SDP will end up extracting the browser's SDP and recreate their own SDP instead.

Given how tough it is for two browser vendors (who even have access to each other's source code) to get this SDP negotiation right, I'm extremely concerned about an entire planet of devices getting this stuff right.

The trouble isn't that SDP isn't expressive enough or it's too ugly a format, it's that it's too expressive (okay, and it's ugly too). The trouble isn't that it's easy to negotiate O/A only for simple cases, it's that when we end up having to signal this stuff in "our own way", we'll be fighting with an O/A state negotiation machine instead of controlling the RTP engine directly with knobs and dials.

As a developer, I want:
1) to control what the RTP engine does on the wire (to ensure compatibility between devices);
2) strict, well defined, easy-to-understand API contracts that do not change, and are only extended in well defined ways;
3) knobs and dials to control the exposed capabilities, and _not_ a negotiation machine to not fight where I can only indirectly "do what I want";
4) predictable outputs, i.e. not having random extensions or odd differences in the middle some blob format show up from version-to-version, and from browser-to-browser;


I do not believe we can address these by tweaking the SDP format, or defining SDP better, or making wrappers for SDP.

The problem is fundamentally SDP O/A as the mandated.


-Robin


19 July, 2013 9:24 PM


Well lets prioritize fixing them. Which ones are causing interoperability problems between browsers?
--------------060002030301030201000606 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDyz4PaTo91ev8AGf40X1vcT34tbmOa/wBO gmkuZXt0Z5XdkLZLk4XcAAAAAAAOGtXvLkienQw6UfaSPQdW17wh4u1VtT8Dato0tvs8u4t/ 7JtiUwxb5dyblyTnuK53KcdztUIVFdHiM2rXVt8arFpItOsIEu1JaHToInKkgZSREDK+cEMC CCAe1dlOpeB51Wnadz17/hq74jf9Fj8Wf+A1p/hT+8wt5GjY/E/4f3HgPSPDI0ptRSbTba2S O1wWysKDJBxg/WuRwnSm7rU9qnJKHLIxNT+Euj6B8LNd8Y+AzKmr3sUbWnnlf3LlgNuFO3gc Y9etVZy1nsDpezi/ZnzjpyeOdW+Jel6dqS+ZqOkSxzXO5QDtaRdpPbjg8+tdNOEVFtHmVHLm SYz+0Piv/wBBHVf/AAGH/wARWnMzG8e5k2Nzf6fPA9x9p0280/ZE3mM0TxyRqFZGBwQQQQR1 HNdbiprU9iH7yCufQPwJ+FXxU+OGtjw74F1GX+ztVfzr+SSY/ZbRMjdO+3jIxgDAZjjr1rz6 lNuXKkc9Wt7Bbn6L/AT9jH4Z/APW9V+Imo6vP4k8TXyDzdV1FEiitIVUArFGOFGByzFj7iui MVBWR5VSq6ruzxD+w/EX/Qq6j/4Av/8AE1V2Zn55/tr/APJzHj7/AK/0/wDREdX0O/7KOx/Y f6+J/wDrna/zelI56+yPsPwf/wAjbof/AGEbb/0atSYH6JUAf//Z --------------060002030301030201000606-- --------------070004090408090607010201-- From bernard_aboba@hotmail.com Fri Jul 19 20:20:32 2013 Return-Path: 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 1573221E80B8 for ; Fri, 19 Jul 2013 20:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.832 X-Spam-Level: X-Spam-Status: No, score=-101.832 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 ELX8weLbQmxn for ; Fri, 19 Jul 2013 20:20:27 -0700 (PDT) Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by ietfa.amsl.com (Postfix) with ESMTP id 437F511E816E for ; Fri, 19 Jul 2013 20:20:27 -0700 (PDT) Received: from BLU403-EAS141 ([65.55.116.72]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Jul 2013 20:20:26 -0700 X-TMN: [jrcVlf/sqNfnCLIQmZ+OouVhoXiQVNrR] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_b9b02ae9-e51c-4c7a-a4d9-644c5e3a5afa_" References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> <1CFEEBBF-DD98-4EDA-9595-F4E3ACB8A94F@iii.ca> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Fri, 19 Jul 2013 20:20:25 -0700 To: Peter Thatcher X-OriginalArrivalTime: 20 Jul 2013 03:20:26.0942 (UTC) FILETIME=[1467B5E0:01CE84F8] Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 03:20:32 -0000 --_b9b02ae9-e51c-4c7a-a4d9-644c5e3a5afa_ Content-Type: multipart/alternative; boundary="Apple-Mail-F33FFB81-2009-4BCD-8D73-D70E510FE1A2" Content-Transfer-Encoding: 7bit --Apple-Mail-F33FFB81-2009-4BCD-8D73-D70E510FE1A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You can remove my line in the spreadsheet, but the residue of my bit presenc= e may remain, polluting nearby cells. I recommend use of bit bleach.=20 On Jul 19, 2013, at 7:10 PM, "Peter Thatcher" wrote: > Like I said when I first sent the summary, anyone is welcome to make a dif= ferent summary from the raw data, or collect their own data. I haven't been= around long enough to know how to categorize people and whose input is cons= idered valuable and whose isn't, so I ignorantly gave everyone equal weight.= So if you'd like, you can filter out Bernard and recalculate. >=20 >=20 > On Jul 19, 2013 6:52 PM, "Cullen Jennings" wrote: >>=20 >> On Jul 19, 2013, at 6:24 PM, Peter Thatcher wrote:= >>=20 >> > You're surprised that the first web developers that try out WebRTC and h= ave feedback have experience with SIP and VoIP? We shouldn't find that surp= rising, nor should we discount their feedback because of it. >>=20 >> I was not saying that feedback from folks like Bernard Aboba was not usef= ul, of course it can be. I was just noting the sample set. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-F33FFB81-2009-4BCD-8D73-D70E510FE1A2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
You can remove my line in the spreadsheet, but the residue of my bit presence may remain, polluting nearby cells. I recommend use of bit bleach. 

On Jul 19, 2013, at 7:10 PM, "Peter Thatcher" <pthatcher@google.com> wrote:

Like I said when I first sent the summary, anyone is welcome to make a different summary from the raw data, or collect their own data.  I haven't been around long enough to know how to categorize people and whose input is considered valuable and whose isn't, so I ignorantly gave everyone equal weight.  So if you'd like, you can filter out  Bernard and recalculate.

On Jul 19, 2013 6:52 PM, "Cullen Jennings" <fluffy@iii.ca> wrote:

On Jul 19, 2013, at 6:24 PM, Peter Thatcher <pthatcher@google.com> wrote:

> You're surprised that the first web developers that try out WebRTC and have feedback have experience with SIP and VoIP?  We shouldn't find that surprising, nor should we discount their feedback because of it.

I was not saying that feedback from folks like Bernard Aboba was not useful, of course it can be. I was just noting the sample set.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--Apple-Mail-F33FFB81-2009-4BCD-8D73-D70E510FE1A2-- --_b9b02ae9-e51c-4c7a-a4d9-644c5e3a5afa_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_b9b02ae9-e51c-4c7a-a4d9-644c5e3a5afa_-- From pthatcher@google.com Fri Jul 19 20:28:32 2013 Return-Path: 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 AD7C911E81D2 for ; Fri, 19 Jul 2013 20:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.207, 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 5Dgm1RjhQaML for ; Fri, 19 Jul 2013 20:28:32 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 17A8B11E81D0 for ; Fri, 19 Jul 2013 20:28:32 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so5122378pab.27 for ; Fri, 19 Jul 2013 20:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ddenJDSij6trHMMOCCQMYtCUh5mTMuOcaAwIBHAgN7U=; b=Qxadcfwg9pkJbd+sRHXH3Kb55XkirA/D4jlkMfAoTIn7VFDQCcmVdSAQFh3uy3wwlW M+8kP8mPGdt6QgKITMTUAUhsIxIXY6t25w6OGmtV7ddFardDcUz7SSviEYtjztpqqy4Z hf/UGnYx/g9j4yB05MClvQFjwR4APL6SdysqQ9YujeJ00Ztohkr5VI/TTLB8jEuETQJ+ AJ9vvQwyQfrrvoRdW9qBqkvM+tS2ZJuWcWOrY9q5TEu+YrFRFjLJNIszIHdacaGhYNoB DD7aeIiKmuf6bPRCov7Xp2VyKoif8+B7Pyc7kmrqnRQC8WX3uG/swABORhTvi/nYi3Ql iLPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ddenJDSij6trHMMOCCQMYtCUh5mTMuOcaAwIBHAgN7U=; b=hJwWZ53qhMRe47v4/zCpemyf8x8OULmuc0p/YnCwObHyJE7hZGf9XEFK37iePpoMd3 x1hX0oy0HX2fi/qFsob5ED+BVbmgp22ZZndYn6oLW8AS2ZC9ur/EqfDFq5duqKGANQZj z3GoLXDcSZ9My7TM7i06fpMVFU6zRFBkeZz0Xn0Tl9gF0X0TiraLN0WS+mx821IzBGOl FdSmxrcwsCKAQbMYKErQv6l9FiiqjzoFkYR6g23edr99WdrmJRJqmGSWyX3SuAwlttv8 lSNIp3njWCcwrcyPAlO7YNBT7r9zvgkFJs7YWw5D+YOne53sEq7yaeaht6l1zQ2oWTS6 A5hg== MIME-Version: 1.0 X-Received: by 10.68.104.196 with SMTP id gg4mr20550084pbb.25.1374290911741; Fri, 19 Jul 2013 20:28:31 -0700 (PDT) Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 20:28:31 -0700 (PDT) Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 20:28:31 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> <1CFEEBBF-DD98-4EDA-9595-F4E3ACB8A94F@iii.ca> Date: Fri, 19 Jul 2013 20:28:31 -0700 Message-ID: From: Peter Thatcher To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7b6705b99cef4a04e1e909d5 X-Gm-Message-State: ALoCoQmPXdEAGcX9V3hHlF+f4GSAtA3dgjdxMtC5zWaB+5bJ/TjssXyiicFQcqF/G545Xmm3DMU+UDNnR473SV3BVHuVvvtmTwFA4+KiL3vV2IkTNGP9Fu08bq0wgtD85LA8wwJixUkkgAee1suwOT+22EeLLuaPKXA3d4dTbkutpUXHLhL54qSZP779OuBl819qXyahLn2H Cc: rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 03:28:32 -0000 --047d7b6705b99cef4a04e1e909d5 Content-Type: text/plain; charset=UTF-8 Best to nuke the spreadsheet from orbit. It's the only way to be sure. On Jul 19, 2013 8:20 PM, "Bernard Aboba" wrote: > You can remove my line in the spreadsheet, but the residue of my bit > presence may remain, polluting nearby cells. I recommend use of bit bleach. > > On Jul 19, 2013, at 7:10 PM, "Peter Thatcher" > wrote: > > Like I said when I first sent the summary, anyone is welcome to make a > different summary from the raw data, or collect their own data. I haven't > been around long enough to know how to categorize people and whose input is > considered valuable and whose isn't, so I ignorantly gave everyone equal > weight. So if you'd like, you can filter out Bernard and recalculate. > > On Jul 19, 2013 6:52 PM, "Cullen Jennings" wrote: > >> >> On Jul 19, 2013, at 6:24 PM, Peter Thatcher wrote: >> >> > You're surprised that the first web developers that try out WebRTC and >> have feedback have experience with SIP and VoIP? We shouldn't find that >> surprising, nor should we discount their feedback because of it. >> >> I was not saying that feedback from folks like Bernard Aboba was not >> useful, of course it can be. I was just noting the sample set. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b6705b99cef4a04e1e909d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Best to nuke the spreadsheet from orbit.=C2=A0 It's the = only way to be sure.

On Jul 19, 2013 8:20 PM, "Bernard Aboba&quo= t; <bernard_aboba@hotmail.c= om> wrote:
You can remove my line in the spreadsheet, but the r= esidue of my bit presence may remain, polluting nearby cells. I recommend u= se of bit bleach.=C2=A0

On Jul 19, 2013, at 7:10 PM, "Pe= ter Thatcher" <pthatcher@google.com> wrote:

Like I said when I = first sent the summary, anyone is welcome to make a different summary from = the raw data, or collect their own data.=C2=A0 I haven't been around lo= ng enough to know how to categorize people and whose input is considered va= luable and whose isn't, so I ignorantly gave everyone equal weight.=C2= =A0 So if you'd like, you can filter out=C2=A0 Bernard and recalculate.=

On Jul 19, 2013 6:52 PM, "Cullen Jennings&q= uot; <fluffy@iii.ca> wrote:

On Jul 19, 2013, at 6:24 PM, Peter Thatcher <pthatcher@google.com> wrote:

> You're surprised that the first web developers that try out WebRTC= and have feedback have experience with SIP and VoIP? =C2=A0We shouldn'= t find that surprising, nor should we discount their feedback because of it= .

I was not saying that feedback from folks like Bernard Aboba was not useful= , of course it can be. I was just noting the sample set.
___________________= ____________________________
rtcweb mailing list
= rtcweb@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/rtcweb
--047d7b6705b99cef4a04e1e909d5-- From matthew.kaufman@skype.net Fri Jul 19 20:39:21 2013 Return-Path: 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 3AB4011E81DA for ; Fri, 19 Jul 2013 20:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1] 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 fwV0mzDRhsr1 for ; Fri, 19 Jul 2013 20:39:15 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6094C21E80B8 for ; Fri, 19 Jul 2013 20:39:11 -0700 (PDT) Received: from mail121-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE028.bigfish.com (10.243.66.91) with Microsoft SMTP Server id 14.1.225.22; Sat, 20 Jul 2013 03:39:10 +0000 Received: from mail121-co1 (localhost [127.0.0.1]) by mail121-co1-R.bigfish.com (Postfix) with ESMTP id 7876D7002A0; Sat, 20 Jul 2013 03:39:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail121-co1: 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=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail121-co1 (localhost.localdomain [127.0.0.1]) by mail121-co1 (MessageSwitch) id 1374291548139919_19586; Sat, 20 Jul 2013 03:39:08 +0000 (UTC) Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.225]) by mail121-co1.bigfish.com (Postfix) with ESMTP id 14FBE4C004A; Sat, 20 Jul 2013 03:39:08 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 20 Jul 2013 03:39:07 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Sat, 20 Jul 2013 03:37:21 +0000 From: "Matthew Kaufman (SKYPE)" To: Cullen Jennings , Peter Thatcher Thread-Topic: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Thread-Index: AQHOhI9UnMKyp9V4L0afmg4M8yPd65lszSOAgAAZsHA= Date: Sat, 20 Jul 2013 03:37:20 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> In-Reply-To: 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="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: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 03:39:21 -0000 From: Cullen Jennings [mailto:fluffy@iii.ca]: >=20 > Well that was clearly one or my more mindless emails >=20 > What I mean to say was something along lines of >=20 > Folks want to sort out the multiplexing / bundle stuff first. >=20 > So let me suggest that folks read section 6 of the JSEP draft and see if = they > can answer most of of the questions below. I'm not saying that section 6 = is > right, in fact I think some of it is wrong. But at least act like you hav= e read it. >=20 Well, first off the "JSEP draft" is an Internet Draft, and I thought we wer= e writing a W3C API here. But I'll play along this time. I'm assuming of co= urse that we're all talking about the latest JSEP draft, which appears to b= e draft-ietf-rtcweb-jsep-03, wherein "section 6" is only a page and a third= long. > > > Can I... > > > - Change the t=3D line to be something other than t=3D0 0? >=20 > Current JSEP draft says the browser does not need to allow that to be > changed. Where? Don't see that at all. >=20 > > > - Change the rtpmap associations before calling setLocal? >=20 > you can remove or reorder But can I change which numbers are assigned? Like if I want 115 for opus in= stead of 112? >=20 > > > - Change a=3Dsendrecv to a=3Drecvonly before calling setLocal? >=20 > Current JSEP draft says that is done with constraints And it says "these changes may also be be performed by manipulating the SDP= returned from createOffer/createAnswer" (and yes, it really does say "be b= e") So I guess the answer to this one is "yes" >=20 > > > - What do you do when you see a=3Dcontent:sl ? >=20 > not in current spec but you can find dissection on list about making sure= that > is available to API Agreed, not specified. >=20 > > > - What if someone adds an r=3D or p=3D or e=3D? >=20 > Current JSEP draft says the browser does not need to allow that No, it says that since should accept valid SDP, it should accept it. At lea= st that's how I read the spec. >=20 > > - What is the RFC that describes a=3Dgroup:BUNDLE (as seen in some brow= ser > implementations)? >=20 > Uh, I'll leave that as an exercise to the readers. Try hard and see if yo= u can > find it. Appears to be work in progress in the MMUSIC WG. So no normative spec that = can be referenced. Guess it must not be allowed, huh? > > > - Can I remove a=3Dgroup:BUNDLE (or add it) before calling setLocal? >=20 > Current JSEP draft says that is done with constraints (Or by modifying the SDP, see above... and there's no API for said constrai= nt) >=20 > > > - How about removing a=3Drtcp-mux? >=20 > Current JSEP draft says that is done with constraints (Or by modifying the SDP, see above... and no API for this constraint eithe= r) >=20 >=20 > > > - Should I do something special at my end if you set a=3Dice-options:= google- > ice ? >=20 > Do whatever the ice spec say Section 15.5 of RFC5245 says absolutely nothing about what I'm supposed to = do with this. And that's the only place a=3Dice-options is discussed. >=20 > > > - If you put a=3Dssrc lines in there, can I change the ssrc before pa= ssing it > back to setLocal? > Current JSEP draft says the browser does not need to allow that to be > changed. Not true. The current spec says that the non-changeable lines are the "numb= er, type and port number of m-lines" "the generated ICE credentials" and "t= he set of ICE candidates and their parameters".=20 Section 4.1 R-8 suggests that RFC5576 MUST be implemented to signal RTP SSR= C values, but nowhere does it tell me (and especially not in section 6) if = the browser will or should let me change them between createOffer and setLo= cal. >=20 >=20 > > > - Can I delete the a=3Dssrc lines? >=20 > Current JSEP draft says the browser does not need to allow that to be > changed. Disagree. See above. >=20 >=20 > > > - Is a=3Drtcp:1 IN IP4 0.0.0.0 valid or not? >=20 > Why would a browser want to generate that? I don't know. I have output from browsers that have generated that in the p= ast. Was that a bug? >=20 > > > - What about 0.0.0.0 in the o=3D line? >=20 > Why would a browser want to generate that? (Same as previous comment) >=20 > > > - If I get a bunch of a=3Dcandidate lines, can I swap them around to = change > the priority before calling setLocal? >=20 > Current JSEP draft says the browser does not need to allow that to be > changed. This appears to be correct. Which is of course unfortunate, as I might very= well wish to do this. Or delete candidates, which also appears to be forbi= dden in section 6, despite several *very* valid use cases for deleting cand= idates a browser happens to generate. >=20 > > > - What if someone claims SAVP instead of SAVPF but gives me rtcp info= ? >=20 > We need to add text to explicitly cover that. You can find text on what I= think > we should do for this in > draft-jennings-rtcweb-plan-01 Then we should add that text. To a W3C specification that covers what the b= rowser must do. >=20 >=20 > > > > > > At the *very least* for each and every line that comes from createOff= er > and createAnswer you must be able to answer the following: > > > - Can I delete it? > > > - Duplicate it? > > > - Change it? > > > - If not, how are violation handled? (Both when passed to another > browser at the far end and when these modifications happen before calling > setLocal) > > > - And can I add additional valid SDP to what came from createOffer or > createAnswer and pass it back to setLocal or not? > > > > > > We appear to be nowhere near a document which explains the answers > to these questions, certainly not in the W3C WG, and not in any IETF RFC = or > draft I can locate. >=20 > draft-ietf-rtcweb-jsep-03 has tried to address some of these. I certainly= don't > claim it is perfect but if people have use cases that suggest a change to= this, > love to get text on what it should be. I don't think it is close at all. See above comments. >=20 > Mathew has been very clear along the way of "we need to define X to have > an interoperable system" and for most values of X he has proposed, I agre= e > with him. However, I think we just need to do that and that it actually w= on't > be much work once we get the framework in place to deal with thinks like > how many ports is the RTP using and how many m-lines does the SDP have. Well, at least we do agree that the specification for what the browser must= do should be written down somewhere. What we don't agree on is how trivial that problem is. Matthew Kaufman From matthew.kaufman@skype.net Fri Jul 19 20:42:18 2013 Return-Path: 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 E30FE11E81D9 for ; Fri, 19 Jul 2013 20:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.095 X-Spam-Level: X-Spam-Status: No, score=-3.095 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, HTML_MESSAGE=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 nQeSDhAiNbI5 for ; Fri, 19 Jul 2013 20:42:12 -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 087B911E81D4 for ; Fri, 19 Jul 2013 20:42:11 -0700 (PDT) Received: from mail64-db9-R.bigfish.com (10.174.16.239) by DB9EHSOBE025.bigfish.com (10.174.14.88) with Microsoft SMTP Server id 14.1.225.22; Sat, 20 Jul 2013 03:42:11 +0000 Received: from mail64-db9 (localhost [127.0.0.1]) by mail64-db9-R.bigfish.com (Postfix) with ESMTP id 27B41A800D8; Sat, 20 Jul 2013 03:42:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zz9371Ic89bhc857hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1de097h1de096h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail64-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=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail64-db9 (localhost.localdomain [127.0.0.1]) by mail64-db9 (MessageSwitch) id 1374291728875488_28573; Sat, 20 Jul 2013 03:42:08 +0000 (UTC) Received: from DB9EHSMHS027.bigfish.com (unknown [10.174.16.229]) by mail64-db9.bigfish.com (Postfix) with ESMTP id C5300B00049; Sat, 20 Jul 2013 03:42:08 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS027.bigfish.com (10.174.14.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 20 Jul 2013 03:42:08 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Sat, 20 Jul 2013 03:41:17 +0000 From: "Matthew Kaufman (SKYPE)" To: Peter Thatcher , Cullen Jennings 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+XES8EqmiU0dHnZlsvYcAgAACXYCAACvyIA== Date: Sat, 20 Jul 2013 03:41:16 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <644AB0EE-8889-4940-BA88-33EA653D44DC@iii.ca> In-Reply-To: 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: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A48423718322TK5EX14MBXC266r_" 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 03:42:19 -0000 --_000_AE1A6B5FD507DC4FB3C5166F3A05A48423718322TK5EX14MBXC266r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tcGxldGVseSBhZ3JlZSB3aXRoIFBldGVyIGhlcmUuIFNEUC1iYXNlZCBzeXN0ZW1zIHNob3Vs ZG7igJl0IGJlIGFueSBtb3JlIGltcG9ydGFudCB0aGFuIEguMzIzIG9yIEppbmdsZSBiYXNlZCBz eXN0ZW1zLCBvciB3aGF0ZXZlciBlbHNlIG1pZ2h0IGJlIG91dCB0aGVyZS4NCg0KV2hhdCBJIGRv buKAmXQgdW5kZXJzdGFuZCBpcyB3aHksIHdpdGggc3VjaCBzdHJvbmcgYW5kIHZhbGlkIGZlZWRi YWNrIGZyb20gc28gbWFueSBwZW9wbGUgdHJ5aW5nIHRvIHVzZSB0aGUgQVBJIHRoYXQgZXhpc3Rz IGF0IHByZXNlbnQsIGFueSBXRyBtZW1iZXIgb3IgY2hhaXIgd291bGQgYmUgc3VnZ2VzdGluZyB0 byBQZXRlciB0aGF0IHRoZSByZXNvbHV0aW9uIG9mIHRoaXMgY2xhc3Mgb2YgcHJvYmxlbXMgbXVz dCBiZSBkZWZlcnJlZCB1bnRpbCDigJxhZnRlciAxLjDigJ0uDQoNCklmIHRoZSBjaGFpcnMgYWN0 dWFsbHkgc2FpZCB0aGF0IChhbmQgSSBjYW7igJl0IGZpbmQgaXQgaW4gYW55IHNlYXJjaGVzIEni gJl2ZSBkb25lIG9mIHB1YmxpYyBsaXN0cyksIHRoZW4gSSB0aGluayB3ZSBoYXZlIGEgcHJvYmxl bS4gSWYgdGhlIGRldmVsb3BlcnMgZmVlbCBsaWtlIG5vIG1hdHRlciB3aGF0IHRoZXkgc2F5LCB0 aGV5IGNhbuKAmXQgbWFrZSBhIHBvc2l0aXZlIGltcGFjdCBvbiB0aGUgc3BlY2lmaWNhdGlvbiB0 aGF0IGlzIHByb2R1Y2VkIGJ5IHRoZSBXRywgdGhlbiB3ZSAqZGVmaW5pdGVseSogaGF2ZSBhIHBy b2JsZW0uDQoNCkRvbuKAmXQgd2U/DQoNCk1hdHRoZXcgS2F1Zm1hbg0KDQpGcm9tOiBQZXRlciBU aGF0Y2hlciBbbWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tXQ0KU2VudDogRnJpZGF5LCBKdWx5 IDE5LCAyMDEzIDY6MDEgUE0NClRvOiBDdWxsZW4gSmVubmluZ3MNCkNjOiBNYXJ0aW4gVGhvbXNv bjsgQWRhbSBSb2FjaDsgScOxYWtpIEJheiBDYXN0aWxsbzsgTWF0dGhldyBLYXVmbWFuIChTS1lQ RSk7IDxydGN3ZWJAaWV0Zi5vcmc+OyBwdWJsaWMtd2VicnRjQHczLm9yZw0KU3ViamVjdDogUmU6 IE9uIGJhYmllcyBhbmQgYmF0aHdhdGVyICh3YXMgUmU6IFtydGN3ZWJdIFN1bW1hcnkgb2YgQXBw bGljYXRpb24gRGV2ZWxvcGVycycgb3BpbmlvbnMgb2YgdGhlIGN1cnJlbnQgV2ViUlRDIEFQSSBh bmQgU0RQIGFzIGEgY29udHJvbCBzdXJmYWNlKQ0KDQpUaGUgbG9naWMgb2YgaG93IHRvIHRhbGsg dG8gdGhlIHZpZGVvIGNvbmZlcmVuY2luZyBzeXN0ZW0gZG9lc24ndCBuZWVkIHRvIGJlIGJhY2tl ZCBpbnRvIHRoZSBicm93c2VyLiAgSWYgdGhlIEFQSSBwcm92aWRlcyBlbm91Z2ggY29udHJvbCB0 aGUgSlMsIHRoZSB3ZWIgYXBwIGNhbiBjb250YWluIHRoZSBsb2dpYyB0byB0YWxrIHRvIHRoZSB2 aWRlbyBjb25mZXJlbmNpbmcgc3lzdGVtLg0KDQpJIGtub3cgSSdtIGdvaW5nIHRvIHN0YXJ0IHNv dW5kaW5nIGxpa2UgYSBicm9rZW4gcmVjb3JkLCBidXQgeW91IGJyb3VnaHQgdXAgdmlkZW8gY29u ZmVyZW5jaW5nIHN5c3RlbXMgYXMgYW4gZXhhbXBsZSwgc28gSSB3aWxsIHNheSBpdCBhZ2Fpbjog dGhlcmUgYXJlIGFyZSB2aWRlbyBjb25mZXJlbmNpbmcgc3lzdGVtcyB0aGF0IGRvbid0IHVzZSBT RFAgZm9yIHNpZ25hbGxpbmcuICBGb3IgZXhhbXBsZSwgdGhlcmUgYXJlIHZpZGVvIGNvbmZlcmVu Y2luZyBzeXN0ZW1zIHRoYXQgdXNlIEppbmdsZSBmb3Igc2lnbmFsbGluZy4gIFdvdWxkIEkgZXhw ZWN0IHRoZSBsb2dpYyBvZiBob3cgdG8gc3BlYWsgdG8gdGhhdCB2aWRlbyBjb25mZXJlbmNpbmcg c3lzdGVtIHRvIGJlIGJha2VkIGludG8gdGhlIGJyb3dzZXI/ICBObywgSSB0aGluayBJJ2QgcHJl ZmVyIGl0IHRvIGJlIGJ1aWx0IGludG8gYSB3ZWIgYXBwIGJ1aWx0IG9uIHRvcCBvZiBhIGdvb2Qg QVBJLiAgV2h5IHNob3VsZCBTRFAtYmFzZWQgdmlkZW8gY29uZmVyZW5jaW5nIHN5c3RlbXMgYmUg dHJlYXRlZCBzcGVjaWFsPw0KDQo= --_000_AE1A6B5FD507DC4FB3C5166F3A05A48423718322TK5EX14MBXC266r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Q29tcGxldGVseSBhZ3JlZSB3aXRoIFBldGVyIGhlcmUuIFNEUC1i YXNlZCBzeXN0ZW1zIHNob3VsZG7igJl0IGJlIGFueSBtb3JlIGltcG9ydGFudCB0aGFuIEguMzIz IG9yIEppbmdsZSBiYXNlZCBzeXN0ZW1zLCBvciB3aGF0ZXZlcg0KIGVsc2UgbWlnaHQgYmUgb3V0 IHRoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgSSBkb27igJl0IHVuZGVyc3RhbmQgaXMgd2h5LCB3 aXRoIHN1Y2ggc3Ryb25nIGFuZCB2YWxpZCBmZWVkYmFjayBmcm9tIHNvIG1hbnkgcGVvcGxlIHRy eWluZyB0byB1c2UgdGhlIEFQSSB0aGF0IGV4aXN0cyBhdCBwcmVzZW50LCBhbnkgV0cgbWVtYmVy IG9yIGNoYWlyDQogd291bGQgYmUgc3VnZ2VzdGluZyB0byBQZXRlciB0aGF0IHRoZSByZXNvbHV0 aW9uIG9mIHRoaXMgY2xhc3Mgb2YgcHJvYmxlbXMgbXVzdCBiZSBkZWZlcnJlZCB1bnRpbCDigJxh ZnRlciAxLjDigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB0aGUgY2hhaXJzIGFjdHVhbGx5IHNhaWQgdGhhdCAo YW5kIEkgY2Fu4oCZdCBmaW5kIGl0IGluIGFueSBzZWFyY2hlcyBJ4oCZdmUgZG9uZSBvZiBwdWJs aWMgbGlzdHMpLCB0aGVuIEkgdGhpbmsgd2UgaGF2ZSBhIHByb2JsZW0uIElmIHRoZSBkZXZlbG9w ZXJzIGZlZWwgbGlrZQ0KIG5vIG1hdHRlciB3aGF0IHRoZXkgc2F5LCB0aGV5IGNhbuKAmXQgbWFr ZSBhIHBvc2l0aXZlIGltcGFjdCBvbiB0aGUgc3BlY2lmaWNhdGlvbiB0aGF0IGlzIHByb2R1Y2Vk IGJ5IHRoZSBXRywgdGhlbiB3ZSAqPGI+ZGVmaW5pdGVseTwvYj4qIGhhdmUgYSBwcm9ibGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+RG9u4oCZdCB3ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1hdHRoZXcgS2F1Zm1hbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBldGVyIFRoYXRjaGVyIFttYWls dG86cHRoYXRjaGVyQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5 IDE5LCAyMDEzIDY6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IEN1bGxlbiBKZW5uaW5nczxicj4NCjxi PkNjOjwvYj4gTWFydGluIFRob21zb247IEFkYW0gUm9hY2g7IEnDsWFraSBCYXogQ2FzdGlsbG87 IE1hdHRoZXcgS2F1Zm1hbiAoU0tZUEUpOyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0OzsgcHVibGlj LXdlYnJ0Y0B3My5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE9uIGJhYmllcyBhbmQgYmF0 aHdhdGVyICh3YXMgUmU6IFtydGN3ZWJdIFN1bW1hcnkgb2YgQXBwbGljYXRpb24gRGV2ZWxvcGVy cycgb3BpbmlvbnMgb2YgdGhlIGN1cnJlbnQgV2ViUlRDIEFQSSBhbmQgU0RQIGFzIGEgY29udHJv bCBzdXJmYWNlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgbG9naWMgb2YgaG93IHRvIHRhbGsgdG8gdGhlIHZpZGVvIGNvbmZlcmVuY2lu ZyBzeXN0ZW0gZG9lc24ndCBuZWVkIHRvIGJlIGJhY2tlZCBpbnRvIHRoZSBicm93c2VyLiAmbmJz cDtJZiB0aGUgQVBJIHByb3ZpZGVzIGVub3VnaCBjb250cm9sIHRoZSBKUywgdGhlIHdlYiBhcHAg Y2FuIGNvbnRhaW4gdGhlIGxvZ2ljIHRvIHRhbGsgdG8gdGhlIHZpZGVvIGNvbmZlcmVuY2luZyBz eXN0ZW0uICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBrbm93IEknbSBnb2luZyB0byBzdGFydCBzb3VuZGluZyBsaWtlIGEgYnJva2VuIHJlY29y ZCwgYnV0IHlvdSBicm91Z2h0IHVwIHZpZGVvIGNvbmZlcmVuY2luZyBzeXN0ZW1zIGFzIGFuIGV4 YW1wbGUsIHNvIEkgd2lsbCBzYXkgaXQgYWdhaW46IHRoZXJlIGFyZSBhcmUgdmlkZW8gY29uZmVy ZW5jaW5nIHN5c3RlbXMgdGhhdCBkb24ndCB1c2UgU0RQIGZvciBzaWduYWxsaW5nLiAmbmJzcDtG b3IgZXhhbXBsZSwgdGhlcmUNCiBhcmUgdmlkZW8gY29uZmVyZW5jaW5nIHN5c3RlbXMgdGhhdCB1 c2UgSmluZ2xlIGZvciBzaWduYWxsaW5nLiAmbmJzcDtXb3VsZCBJIGV4cGVjdCB0aGUgbG9naWMg b2YgaG93IHRvIHNwZWFrIHRvIHRoYXQgdmlkZW8gY29uZmVyZW5jaW5nIHN5c3RlbSB0byBiZSBi YWtlZCBpbnRvIHRoZSBicm93c2VyPyAmbmJzcDtObywgSSB0aGluayBJJ2QgcHJlZmVyIGl0IHRv IGJlIGJ1aWx0IGludG8gYSB3ZWIgYXBwIGJ1aWx0IG9uIHRvcCBvZiBhIGdvb2QgQVBJLiAmbmJz cDtXaHkNCiBzaG91bGQgU0RQLWJhc2VkIHZpZGVvIGNvbmZlcmVuY2luZyBzeXN0ZW1zIGJlIHRy ZWF0ZWQgc3BlY2lhbD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AE1A6B5FD507DC4FB3C5166F3A05A48423718322TK5EX14MBXC266r_-- From matthew.kaufman@skype.net Fri Jul 19 20:45:09 2013 Return-Path: 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 D40B711E81D4 for ; Fri, 19 Jul 2013 20:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 9ddq26VfmcE3 for ; Fri, 19 Jul 2013 20:45:03 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 8C36311E81DB for ; Fri, 19 Jul 2013 20:45:02 -0700 (PDT) Received: from mail185-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE033.bigfish.com (10.243.66.98) with Microsoft SMTP Server id 14.1.225.22; Sat, 20 Jul 2013 03:45:02 +0000 Received: from mail185-co1 (localhost [127.0.0.1]) by mail185-co1-R.bigfish.com (Postfix) with ESMTP id D9FAC2C014C; Sat, 20 Jul 2013 03:45:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1de097hz2fh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail185-co1: 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=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail185-co1 (localhost.localdomain [127.0.0.1]) by mail185-co1 (MessageSwitch) id 1374291899286510_3967; Sat, 20 Jul 2013 03:44:59 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.229]) by mail185-co1.bigfish.com (Postfix) with ESMTP id 381145C004A; Sat, 20 Jul 2013 03:44:59 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 20 Jul 2013 03:44:58 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Sat, 20 Jul 2013 03:42:52 +0000 From: "Matthew Kaufman (SKYPE)" To: Cullen Jennings 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+XES8EqmiU0dHnZlsVW5ggABphgCAAC3PEA== Date: Sat, 20 Jul 2013 03:42:51 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 03:45:10 -0000 Cullen Jennings [mailto:fluffy@iii.ca]: >=20 > On Jul 19, 2013, at 11:40 AM, Matthew Kaufman (SKYPE) > wrote: >=20 > > From: Martin Thomson [mailto:martin.thomson@gmail.com] > >> > >> Negotiation is a hole. A vast, soul-sucking, waste of time. > > > > And negotiation over SDP requires a trip to MMUSIC every time you think > of something new, too. That's a soul-sucking waste of time *itself*. > > > > Matthew Kaufman >=20 > Better than a trip to W3C, IETF, and XSF >=20 One successfully early trip to the W3C to get some JS APIs that let me buil= d anything I want later is a hell of a lot better than one trip to MMUSIC (= when I'm already on a deadline, no doubt) every time I come up with an idea= in the future. I know you know this, so I don't know why you would say what you said. Matthew Kaufman From ibc@aliax.net Sat Jul 20 07:04:24 2013 Return-Path: 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 B3C6621F9655 for ; Sat, 20 Jul 2013 07:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 et+evFYosV0B for ; Sat, 20 Jul 2013 07:04:19 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id EDA3021F9C2D for ; Sat, 20 Jul 2013 07:04:16 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so2958223qeb.31 for ; Sat, 20 Jul 2013 07:04:16 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=YL0L+RmRwPnZkRxgEyMmBuj7dfH1gRX4CUkfFCnsHb0=; b=JGQpz4x5fZg3Z6OaoFQkIw0DNloDUBK8aTGogcXwwb3GUPuJsaH+p/GtQHGOU36c9d uvdBOVvXlpdmoKUw7AE2cEnbVyhsxHXPIL/Qqv6sdp1n8ptskEXFjU4jZvJck5KFugq6 0mOuIqw4Du1aMhErrHlkSbF0THYzfbeoi3F0kH64fEhrwW3BvlHzFjfKefK85mf0VO2T NaiPLybWNGA+yeAAbUBnCp1fVFKq2wZkrIFB90pBl3/G12tMuvxdE1dPi5B2Pt3gIJrc 5WBwXh+ejeQErwUaAQePLAjjrs0y/ZRuwd+lPpFpiYVqf2nggpfrO+7r+R9Njsy9B4y8 Jp3g== X-Received: by 10.49.84.164 with SMTP id a4mr22954896qez.4.1374329056375; Sat, 20 Jul 2013 07:04:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Sat, 20 Jul 2013 07:03:56 -0700 (PDT) In-Reply-To: <644AB0EE-8889-4940-BA88-33EA653D44DC@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <644AB0EE-8889-4940-BA88-33EA653D44DC@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 20 Jul 2013 16:03:56 +0200 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmKyu1YYbOPyhlnWomltdBMV/4aWVVjyRpRun+TPX612RZj88UMZHpjlaLu5ncgNHqrVmFi Cc: "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 14:04:24 -0000 2013/7/20 Cullen Jennings : > 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 vend= or. In the WWW, the servide provider provides both the server side (in this case the Web and the video conference server) and the client side (the JS). Your concern is good for a SIP phone but not for a browser nor for a JS custom application controlled and designed by the provider. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Sat Jul 20 07:12:29 2013 Return-Path: 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 C42B111E8103 for ; Sat, 20 Jul 2013 07:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 w0Slu2FIUS21 for ; Sat, 20 Jul 2013 07:12:24 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8E00311E810E for ; Sat, 20 Jul 2013 07:12:24 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u12so2831341qcx.12 for ; Sat, 20 Jul 2013 07:12:24 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=KFRU790ni1rlxq7XSRdfjCSghSseip6PTGYGHCf2s20=; b=O/8zL2B6wKBXjUOw6JojBmLAUr5SIXoYn4CVw7cxL1FVB/Rf8iTfRnxvh/Edd6VbWk TvAblnYmo4J1NIhp2hWSgKp6+85ZtZ4oHXGL+whDOyWtdnFO/zTZmginjsz46zj9XxO7 xr8Iw3bwluvjhJg8iTwBe/aWkTD452mEVx2i69876IxNbUHfi7/9m8HOuyX5o0KyQ0Fn QYg5cTxMxtKsaOmPKqSWG1V83I+e9j+PznnIhmNTwNJ2xh7En0cYOv9Jw0GRbCIjTKrM MfrlDmFFPmsemzU542GmO/R64rNsyFXb1qFp0wJBeOSWeollm2zHFu0X+Ny89/gWPFy9 qBrg== X-Received: by 10.229.171.2 with SMTP id f2mr5278933qcz.24.1374329543992; Sat, 20 Jul 2013 07:12:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Sat, 20 Jul 2013 07:12:03 -0700 (PDT) In-Reply-To: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <51E96B5B.2050302@nostrum.com> <644AB0EE-8889-4940-BA88-33EA653D44DC@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 20 Jul 2013 16:12:03 +0200 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmVvnPSUfEXkNyN9L3m0yeutONhMqmgn+6z0y9FgZruI+verm+XrduSAL54QItyYsYaw5m7 Cc: "public-webrtc@w3.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 14:12:29 -0000 2013/7/20 I=C3=B1aki Baz Castillo : > 2013/7/20 Cullen Jennings : >> 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 ven= dor. > > In the WWW, the servide provider provides both the server side (in > this case the Web and the video conference server) and the client side > (the JS). Your concern is good for a SIP phone but not for a browser > nor for a JS custom application controlled and designed by the > provider. Cullen, could you please give your opinion about what I've said above? I also would like to know what happens if the video conference server uses Jingle or any future RTC protocol (which uses RTP but no SDP for media sig). Thanks a lot. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Sat Jul 20 07:26:32 2013 Return-Path: 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 747EE21F9F85 for ; Sat, 20 Jul 2013 07:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 PV2q3+A9M7-s for ; Sat, 20 Jul 2013 07:26:27 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 50BB321F9655 for ; Sat, 20 Jul 2013 07:26:27 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so2955363qea.35 for ; Sat, 20 Jul 2013 07:26:25 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=iWyhphoOXRDmjUi6aKm1VZeEiX9PejEZLBWSknt8How=; b=QCJV0iIptA3yfnEXjjorxtULWGzQbOmdss3UIiHniVfsN/yp0znkxB4+dKTfzRIAV0 AwiXx51iNesK06m8yjHo0p5Dwk+2lv/Z0vOw+Tupbi9TRIhzKIICkbTSK5TBoDgZka6s wC2EBdazX3Pv2+ju9fGhZRR/OixkExTYOC+gdxGbCrIWcOCwGnuy/9XNwRMeNm3Eg5G1 WzYZBr5C/UiFX2ahG6HdRKZOyzzh8UZstZs4+imCFIwHwfUjK5xgQlPeDkYRKSuUydqV aKNE+Yjy1lh2u7Esld2c5/jpBU/L2D61VJDHQIN8wHO4ae6CzDsBmL1hhb7rntKUfVgW 3Oyw== X-Received: by 10.224.22.67 with SMTP id m3mr23919183qab.36.1374330385678; Sat, 20 Jul 2013 07:26:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Sat, 20 Jul 2013 07:26:05 -0700 (PDT) In-Reply-To: <0D2B47D9-25BF-40C1-AC41-DF65093A6B94@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> <0D2B47D9-25BF-40C1-AC41-DF65093A6B94@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 20 Jul 2013 16:26:05 +0200 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkzseAVsgWx9/t6CHkOAZotuUIABndukRNTFJwNL9Ad0QU/jR9aN/CNAe7A/3cQKRL8FOlX Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 14:26:32 -0000 2013/7/20 Cullen Jennings : > I will note that over half of that very small sample set is folks that ha= ve been long termed involved in SIP and VoIP so, uh, might not be a represe= ntative sample of type of people you are portraying it as. It is even worse if people interested and expert in SIP tells you that the current SDP-blob-based API is really wrong for using SIP in WebRTC, don't you think? -- I=C3=B1aki Baz Castillo From ibc@aliax.net Sat Jul 20 07:28:11 2013 Return-Path: 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 DF84811E8110 for ; Sat, 20 Jul 2013 07:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 kOGHSyj9+rro for ; Sat, 20 Jul 2013 07:28:06 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 68D4D21F9F85 for ; Sat, 20 Jul 2013 07:28:04 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id cr7so208958qab.15 for ; Sat, 20 Jul 2013 07:28:02 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=Z+JliwE7o5dbVZYcaHV0R9URQc77bStcNoH67cxgbF0=; b=K4/i8+i+qJaqRg8x6ETlRo8xNFrOIGJtvZ1BPCGiWhQTBk58Q8GFud683YjzFm5ZVV e74v1LDqE4dBQ0qBjIbqYcgdVWcC/fIsx8vjQqJ8nDuvsfKHZWUU1i4j4+aHhaqB2mtt ytTka0s1VvPDsQ0HQAtFmoUJmgzUf7SLOrDyWkVsDa0aIZ4CsUh46Y0gSyla3KVHOqk0 3B9Ch8WgQCZRy7iaJlqKu0S+SWXM2oasqUhnGu3g7eMi2cPsJY6HM5tDaCrjs5G/73jR lNSAl3WvTlxH3/WWt3XVPCwXd/9911/8+zuP/++aqEys9N11ffYe5jJCKAwBJpv7rp8V FhsA== X-Received: by 10.49.116.176 with SMTP id jx16mr22624498qeb.52.1374330482840; Sat, 20 Jul 2013 07:28:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Sat, 20 Jul 2013 07:27:42 -0700 (PDT) In-Reply-To: <3C837643-5DB1-4192-8DA3-6D999E867E77@iii.ca> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <3C837643-5DB1-4192-8DA3-6D999E867E77@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 20 Jul 2013 16:27:42 +0200 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk3puyYglSuow8iSfmEQcQZRfv2Gz++FyAyzJcu6V9V61MP1C8dPBOa+Jmwd397vP+dBzid Cc: "" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 14:28:12 -0000 2013/7/20 Cullen Jennings : > Well lets prioritize fixing them. Which ones are causing interoperability= problems between browsers? This means wasting time fixing SDP related issues that, once are fixed, provides *nothing* useful to WebRTC. -- I=C3=B1aki Baz Castillo From yekuiw@qti.qualcomm.com Sat Jul 20 08:40:09 2013 Return-Path: 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 01B561F0D1D; Sat, 20 Jul 2013 08:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.223 X-Spam-Level: X-Spam-Status: No, score=-105.223 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 JvlecyZaWnQs; Sat, 20 Jul 2013 08:40:05 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8612411E810C; Sat, 20 Jul 2013 08:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374334801; x=1405870801; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mwm9rSlGv23oC79tliCcSi0rPW/VH8jIcHCJI/itmOQ=; b=YAOPb5KUrIcaDYRuNfosuSZs8aYCkC6eeJvOCOeXgThhKnB9NEZDAtaJ JAZbCXdF55p6K8U0MyzPXOIVTuCbSAcV8Jk8ecjo2vDXXU18CK+cuZWbJ qkuFkTNUgD/77L0JPLiB9l4Pm3Hv78WmXj87yvzUi2AZIWI7Lox+yv0J+ M=; X-IronPort-AV: E=Sophos;i="4.89,708,1367996400"; d="scan'208,217";a="63872191" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 20 Jul 2013 08:40:00 -0700 X-IronPort-AV: E=Sophos;i="4.89,708,1367996400"; d="scan'208,217";a="507750403" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Jul 2013 08:39:59 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.108]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.02.0318.004; Sat, 20 Jul 2013 08:39:59 -0700 From: "Wang, Ye-Kui" To: Adam Fineberg Thread-Topic: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOhNLztWy6humvgkWzyBwOZk2sn5lttSKU Date: Sat, 20 Jul 2013 15:39:58 +0000 Message-ID: <18EEAD91-00D1-4EA3-AC11-6B54C69FBCE0@qti.qualcomm.com> References: ,<51E9C371.2090905@vline.me> In-Reply-To: <51E9C371.2090905@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_18EEAD9100D14EA3AC116B54C69FBCE0qtiqualcommcom_" MIME-Version: 1.0 Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 15:40:09 -0000 --_000_18EEAD9100D14EA3AC116B54C69FBCE0qtiqualcommcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just to mention that the family of 3D codecs based on H.264, incl. MVC, MVC= +D, 3D-AVC, and even MFC, developed or being developed, should also be take= n into consideration. BR, YK On Jul 19, 2013, at 15:54, "Adam Fineberg" > wrote: Stephan, On 7/19/13 3:44 PM, Stephan Wenger wrote: Hi, From: Adam Fineberg > Date: Friday, 19 July, 2013 15:12 To: Stephan Wenger > Cc: Justin Uberti >, Bernard = Aboba >, "avtex= t@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at= all familiar with H.265. I'll review the reference and see what I can fig= ure. StW: Good luck :-) It seems though to me that you are suggesting that except in the simple cas= e, that the data for H.265 would not be well suited to a header extension, = am I understanding you correctly? There is no reason the middlebox couldn'= t get out of band signaling of the VPS as you mention but that would not be= within the scope of this header extension. StW: well, if you would copy the layer_id into your header extension (just = as you need to do for the simple case), a really smart middle box could use= this information just as a decoder uses it, assuming that it intercepted t= he VPS in the first place. Insofar, I wouldn't rule out the second option = on technical grounds. Whether any of the actual products would bother to d= o that, ever, is another question. I think the case ought to be documented= , though. I can help drafting text. Any help is appreciated. While we are at it: doing this right could mean that you need multiple spec= s. First, a generic header extension mechanism dedicated to side informati= on required for pruning of RTP packet streams=97ideally not only for scalab= le video, although that is the main customer today. And second, for each "= payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v= 2 (including scalable and 3D extensions, which are not yet finalized), VP8,= and VP9 (I know little about the latter), plus Daala, and whatnot) a mappi= ng of the bits available in the generic header extension to the bits in the= payload itself (NAL header and VPS in case of H.265, NALU header in SVC, a= nd the fields you mention for VP8). I was just thinking about that since it seems like the extension payload ma= ybe completely specific and therefore not suitable for the same spec. The = problem in my mind with taking the hierarchical a[[roach you mention is tha= t I'm not sure what if any common data is suitable accross all codecs and s= ince there is already a spec for the general header extension, the generic = one you mention might be fairly redundant. I'm certainly open to your thoughts though. Regards, Adam Stephan Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling=97as the encrypted in-band VPS would not be useful under the assu= mption that the middle box does not have the key to the media=97which is th= e motivation of the draft in the first place). I personally don't mind at = all the second mechanism, as I'm a big fan of out-of-band parameter set tra= nsmission and any middle box must be in the signaling path anyway to meanin= gfully manipulate RTP. I do not like the first option due to its variable,= and possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal= -layer-ext-00.txt Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for = VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ avtext mailing list avtext@ietf.orghttps://www.ietf.org/mailman/listinf= o/avtext -- Regards, Adam -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_18EEAD9100D14EA3AC116B54C69FBCE0qtiqualcommcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Just to mention that the family of 3D codecs based on H.264, incl. MVC= , MVC+D, 3D-AVC, and even MFC, developed or being developed, should als= o be taken into consideration.

BR, YK

On Jul 19, 2013, at 15:54, "Adam Fineberg" <fineberg@vline.me> wrote:

Stephan,

On 7/19/13 3:44 PM, Stephan Wenger wrote:
Hi,

From: Adam Fineberg <fineberg@vline.me>= ;
Date: Friday, 19 July, 2013 15:12 <= br> To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>= ;, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@iet= f.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd:= New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.t= xt

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm n= ot at all familiar with H.265.  I'll review the reference and see what= I can figure. 

StW: Good luck :-) 

It seems though to me that you ar= e suggesting that except in the simple case, that the data for H.265 would = not be well suited to a header extension, am I understanding you correctly?=   There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be = within the scope of this header extension.

StW: well, i= f you would copy the layer_id into your header extension (just as you need = to do for the simple case), a really smart middle box could use this inform= ation just as a decoder uses it, assuming that it intercepted the VPS in the first place.  Insofar, I wouldn't rule = out the second option on technical grounds.  Whether any of the actual= products would bother to do that, ever, is another question.  I think= the case ought to be documented, though.  I can help drafting text.

Any help is appreciated.

While we are= at it: doing this right could mean that you need multiple specs.  Fir= st, a generic header extension mechanism dedicated to side information requ= ired for pruning of RTP packet streams=97ideally not only for scalable video, although that is the main customer today. &nb= sp;And second, for each "payload" (at present we are talking abou= t H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions,= which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the b= its available in the generic header extension to the bits in the payload it= self (NAL header and VPS in case of H.265, NALU header in SVC, and the fiel= ds you mention for VP8).

I was just thinking about that since it seems like the extension payload ma= ybe completely specific and therefore not suitable for the same spec. = The problem in my mind with taking the hierarchical a[[roach you mention i= s that I'm not sure what if any common data is suitable accross all codecs and since there is already a spec for = the general header extension, the generic one you mention might be fairly r= edundant.

I'm certainly open to your thoughts though.

Regards,
Adam


Stephan


Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough.  For H.264 and VP8 = that has already been demonstrated.  For H.265, some initial thoughts = below.  Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under developm= ent.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_u= ser/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and t= here may well be cases where different pruning strategies may be advisable.=  For example, a layering structure could be constructed that expands = into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By lo= oking at the six bit field alone, a middle box will not be able to meaningf= ully remove NAL units belonging to one of the branches completely while pru= ning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the = dimension_id[][] (and associated control info) in the header extension, or = require the middle box to have access to the VPS and be able to interpret i= ts content.  The further could take considerably more than 16 bits and we would be talking about a variable le= ngth data structure.  The latter requires the middle box to have state= and a mechanism to intercept the VPS (through signaling=97as the encrypted= in-band VPS would not be useful under the assumption that the middle box does not have the key to the media=97wh= ich is the motivation of the draft in the first place).  I personally = don't mind at all the second mechanism, as I'm a big fan of out-of-band par= ameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP. &= nbsp;I do not like the first option due to its variable, and possibly subst= antial, overhead.

Stephan   


From: Justin Uberti <juberti@google.com&= gt;
Date: Friday, 19 July, 2013 06:32 <= br> To: Bernard Aboba <bernard_aboba@hotm= ail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, = "rtcweb@ie= tf.org" <rtcweb@iet= f.org>
Subject: Re: [rtcweb] Fwd: New Vers= ion Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in e= ach case there are fairly low limits on the number of supported layers (i.e= . 3 spatial layers for SVC), I think it should be possible to pack the temp= oral, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <= span dir=3D"ltr"> <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vl= ine.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For e= xample, for H.264/SVC which can support temporal, spatial and quality scala= bility, you would need the quality_id and dependency_id in addition to the = temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with = any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on = WebRTC services and have found that while developing services that forward = VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer infor= mation from the RTP header which requires us to decrypt the SRTP packets. T= his is undesirable both because the middle-box needs to have access to the = keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP he= ader extension that will allow us to use the VP8 temporal layer information= included in the header extension and therefore do forwarding without SRTP = decryption. Comments welcome.

Regards,=
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-0= 0.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineb= erg at vline.com> 


A new version of I-D, dr=
aft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-a=
vtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-=
layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer=
-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

--=20
Regards,
Adam


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



_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

--=20
Regards,
Adam

--=20
Regards,
Adam
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.= ietf.org/mailman/listinfo/rtcweb
--_000_18EEAD9100D14EA3AC116B54C69FBCE0qtiqualcommcom_-- From lijing80@huawei.com Sun Jul 21 18:35:31 2013 Return-Path: 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 15E3721F85E8 for ; Sun, 21 Jul 2013 18:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 cCSYHyx1G9XJ for ; Sun, 21 Jul 2013 18:35:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6CA21F85D1 for ; Sun, 21 Jul 2013 18:35:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATQ65208; Mon, 22 Jul 2013 01:35:20 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 02:34:56 +0100 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 02:35:01 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 09:34:56 +0800 From: "Lijing (Jessie, Technology Introduction & Standard and Patent Dept)" To: Bo Burman , "rtcweb@ietf.org" Thread-Topic: Some thoughts on optional audio codecs Thread-Index: Ac6BN11IugiIgzm2TXug3PomYB8N3AFQBe5g Date: Mon, 22 Jul 2013 01:34:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.171.171] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [rtcweb] =?utf-8?b?562U5aSNOiBTb21lIHRob3VnaHRzIG9uIG9wdGlvbmFs?= =?utf-8?q?_audio_codecs?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 01:35:31 -0000 SSBmdWxseSBhZ3JlZSB3aXRoIHRoZSBpZGVhIHRvICIgdXNlIGV4aXN0aW5nICJuYXRpdmUiIGNv ZGVjcyAiLiANCg0KSW4gYWRkaXRpb24sIGZyb20gYSB3ZWIgZGV2ZWxvcGVyJ3MgcGVyc3BlY3Rp dmUsIGluIG9yZGVyIHRvIG1ha2UgdXNlIG9mIHRoZSAibmF0aXZlIiBjb2RlY3MsIHRoZSBicm93 c2VyIHNob3VsZCBwcm92aWRlIGNvZGVjIEFQSXMgdG8gb3BlbiB0aGUgbG9jYWwgY29kZWMgY2Fw YWJpbGl0aWVzIG9mIHRoZSBkZXZpY2UgdG8gYXBwbGljYXRpb25zIGFuZCBkZXZlbG9wZXJzLiBJ dCByZWFsbHkgbWFrZSBzZW5zZS4NCg0KQmVzdCBSZWdhcmRzDQpMaWppbmcNCg0KDQotLS0tLemC ruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWls dG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBCbyBCdXJtYW4NCuWPkemAgeaXtumX tDogMjAxM+W5tDfmnIgxNeaXpSAyMzoxNQ0K5pS25Lu25Lq6OiBydGN3ZWJAaWV0Zi5vcmcNCuS4 u+mimDogW3J0Y3dlYl0gU29tZSB0aG91Z2h0cyBvbiBvcHRpb25hbCBhdWRpbyBjb2RlY3MNCg0K UmVnYXJkaW5nIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9uIG9uIG9wdGlvbmFsIGF1ZGlvIGNvZGVj cyBpbiB0aGUgKGN1cnJlbnRseSBleHBpcmVkKSBkcmFmdCBvbiBSVENXRUIgYXVkaW8gY29kZWNz IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1hdWRp by8pOg0KDQpJIHRoaW5rIG1vc3QgcGFydGllcyBpbnZvbHZlZCBpbiBXZWJSVEMgd29yaywgbXlz ZWxmIGluY2x1ZGVkLCBob3BlIGFuZCBiZWxpZXZlIHRoYXQgaXQgd2lsbCBiZSB1YmlxdWl0b3Vz IGFuZCBlYXN5IHRvIGluY2x1ZGUgcmVhbC10aW1lIG1lZGlhIGNvbnZlcnNhdGlvbiBmdW5jdGlv bmFsaXR5IGluIG5lYXJseSBhbnkgd2ViIGNvbnRleHQuIFNpbmNlIGl0IHdpbGwgYmUgdGhhdCBl YXN5LCBpdCBjYW4gYmUgZXhwZWN0ZWQgdGhhdCBtb3N0IHdlYiBkZXZlbG9wZXJzIG5lZWQgbm90 IGJlLCBhbmQgdGh1cyB3aWxsIG5vdCBiZSwgbWVkaWEgc3BlY2lhbGlzdHMgb3IgdmVyeSBrbm93 bGVkZ2VhYmxlIGFib3V0IGNvZGVjcy4NCg0KVGhlIGRlZmluaXRpb24gb2YgUlRDV0VCIE1USSBj b2RlY3MgZW5zdXJlcyB0aGF0IGNvbW11bmljYXRpb24gaXMgcG9zc2libGUgc2luY2UgYXQgbGVh c3Qgb25lIGNvZGVjIHdpbGwgYWx3YXlzIGJlIGZvdW5kLCBidXQgaXQgaXMgbm90IHBvc3NpYmxl IHRvIGNsYWltIHRoZSByZXN1bHRpbmcgY29tbXVuaWNhdGlvbiB0byBiZSBvcHRpbXVtIGZvciBl dmVyeSBwb3NzaWJsZSBjb250ZXh0Lg0KDQpFdmVuIGlmIFdlYlJUQyB3aWxsIGJlIGNsb3NlIHRv IHViaXF1aXRvdXMsIHRoZXJlIHdpbGwgZm9yIHF1aXRlIHNvbWUgdGltZSBsaWtlbHkgYmUgYSBk ZXNpcmUgdG8gcmVhY2ggcmVhbC10aW1lIG1lZGlhIGRvbWFpbnMgYW5kIGRldmljZXMgdGhhdCB3 ZXJlIG5vdCBvcmlnaW5hbGx5IGRlc2lnbmVkIGZvciBhbmQgdGh1cyBhcmUgbm90IG9wdGltaXpl ZCBmb3IgdXNlIHdpdGggV2ViUlRDLiBBIGNvbW11bmljYXRpb24gZGV2aWNlIHRoYXQgaXMgbm90 IGRlc2lnbmVkIHNvbGVseSBmb3IgV2ViUlRDIHVzZSB3aWxsIGxpa2VseSBpbmNsdWRlIGZ1bmN0 aW9uYWxpdHkgYW5kIGNvZGVjcyBhbHNvIGZvciBpdHMgIm5hdGl2ZSIgZG9tYWluLg0KDQpBbnkg YWRkZWQgY29zdCBvZiBub3QgYmVpbmcgYWJsZSB0byB1c2UgZXhpc3RpbmcgIm5hdGl2ZSIgY29k ZWNzIHdpbGwgdmFyeSBib3RoIGluIGFtb3VudCBhbmQgd2hlcmUgdGhlIGNvc3QgaGFzIHRvIGJl IHRha2VuLiBFbGltaW5hdGluZyBpdCBpcyBpbmRlZWQgYW4gb3B0aW1pemF0aW9uLCBidXQgdGhl IHRvdGFsIGNvc3Qgc2F2aW5ncyBtYXkgc3RpbGwgYmUgc2lnbmlmaWNhbnQuDQoNCldpdGggdGhl IGN1cnJlbnQgZGVzaWduIGFuZCB0byBteSB1bmRlcnN0YW5kaW5nLCBpdCB3aWxsIGJlIHRoZSBi cm93c2VyIHZlbmRvcidzIGNob2ljZSB0byBhZGQgb3B0aW9uYWwgY29kZWNzLCBpbmNsdWRpbmcg YW55ICJuYXRpdmUiIGRvbWFpbiBjb2RlY3MuICBUaGUgY2hvaWNlIG1heSBwb3NzaWJseSBiZSBk ZWxlZ2F0ZWQgdG8gaW5kaXZpZHVhbCB3ZWIgZGV2ZWxvcGVycyBtYWtpbmcgdXNlIG9mIFdlYlJU QyBmdW5jdGlvbmFsaXR5LiBBIGJyb3dzZXIgdmVuZG9yIHdpbGwgYXJndWFibHkgaGF2ZSB0byBr bm93IGVhY2ggdGFyZ2V0IHBsYXRmb3JtIHRvIHNvbWUgZXh0ZW50LCBidXQgaXQgY2FuIGhhcmRs eSBiZSBhc3N1bWVkIHRoYXQgYSB3ZWIgZGV2ZWxvcGVyIGtub3dzIHRoZSBjYXBhYmlsaXRpZXMg b2YgYWxsIGRldmljZXMgdGhhdCB3aWxsIHVzZSB0aGUgV2ViUlRDLWVuYWJsZWQgc2l0ZSB1bmxl c3MgdGhlIGJyb3dzZXIgY2FuIHByb3ZpZGUgdGhlIG5lZWRlZCBpbmZvcm1hdGlvbi4gVGhlcmUg aXMgYSByaXNrIHRoYXQgIm5hdGl2ZSIgY29kZWNzIGluIGRldmljZXMgYXJlIG5vdCB3ZWxsIGhh bmRsZWQsIHVubGVzcyB0aGUgbW90aXZhdGlvbnMgYW5kIG1ldGhvZHMgdG8gbWFrZSB1c2Ugb2Yg dGhlbSBhcmUgYmV0dGVyIHNwZWNpZmllZC4NCg0KV2hpbGUgYW55IGF1ZGlvIGNvZGVjcyBiZXNp ZGVzIHRoZSBNVEkgb25lcyBhcmUgY2xlYXJseSBvcHRpb25hbCwgSSBiZWxpZXZlIHRoZSBzdWdn ZXN0ZWQgdGV4dCBhZGRpdGlvbiBvbiBvcHRpb25hbCBhdWRpbyBjb2RlY3MgdG8gdGhlIFJUQ1dF QiBhdWRpbyBkcmFmdCBpbiBUaWNrZXQgIzEyIChodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93 Zy9ydGN3ZWIvdHJhYy90aWNrZXQvMTIjKSB0byBiZSB0b28gYnJpZWYgY29uc2lkZXJpbmcgdGhl IGFib3ZlLg0KDQpJbiB0aGF0IGRyYWZ0LCBJIHdvdWxkIHByZWZlciBzb21ldGhpbmcgbW9yZSBp biBsaW5lIHdpdGg6DQoNCiJJZiBvdGhlciBzdWl0YWJsZSBhdWRpbyBjb2RlY3MgYXJlIGF2YWls YWJsZSB0byB0aGUgYnJvd3NlciB0byB1c2UsIGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhleSBh cmUgYWxzbyBpbmNsdWRlZCBpbiB0aGUgb2ZmZXIgaW4gb3JkZXIgdG8gbWF4aW1pemUgdGhlIHBv c3NpYmlsaXR5IHRvIGVzdGFibGlzaCB0aGUgc2Vzc2lvbiB3aXRob3V0IHRoZSBuZWVkIGZvciBh dWRpbyB0cmFuc2NvZGluZyIuDQoNCkFzc3VtaW5nIHRoYXQgdGhlIGJyb3dzZXIgdmVuZG9yIChv ciB3ZWIgZGV2ZWxvcGVyKSBpcyBzdWZmaWNpZW50bHkgY29uY2VybmVkIHdpdGggY29kZWNzIHRv IHJlYWQgdGhlIGF1ZGlvIGNvZGVjcyBkcmFmdCAob3IgdGhlIGNvcnJlc3BvbmRpbmcgUkZDIHRv LWJlKSwgdGhlIGFib3ZlIHRleHQgbWF5LCBhcyBhIHN0YXJ0LCBnaXZlIHNvbWUgYWRkZWQgZ3Vp ZGFuY2Ugd2h5IG5vbi1NVEkgY29kZWNzIG1heSBiZSBkZXNpcmFibGUgdG8gY29uc2lkZXIgaW4g YWRkaXRpb24gdG8gdGhlIE1USSBvbmVzLg0KDQpDaGVlcnMsDQpCbw0KDQpNdWx0aW1lZGlhIFRl Y2hub2xvZ2llcw0KRXJpY3Nzb24gUmVzZWFyY2gNCkbDpHLDtmdhdGFuIDYNClNFLTE2NCA4MCwg S2lzdGEsIFN3ZWRlbg0Kd3d3LmVyaWNzc29uLmNvbQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From ekr@rtfm.com Sun Jul 21 18:39:49 2013 Return-Path: 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 36C3421F8423 for ; Sun, 21 Jul 2013 18:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] 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 47Pa9icS2LGJ for ; Sun, 21 Jul 2013 18:39:43 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECF721F9A18 for ; Sun, 21 Jul 2013 18:39:39 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c11so3288528qcv.23 for ; Sun, 21 Jul 2013 18:39:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=4iYfInK1yfCS5/R6kc5raCy8tPlIfh0HQiTjCA7dogE=; b=AHAzStI/AhLJYALzfNW2MDlBdi9+HezEYDPxiU9KBYdgcSp1nJh+B8jYfFxo8VyGjF Shyt8ufepA6ZlY3Hb/1tx2L0VXjURFKZXFnpEHMCmyO0MScPfmd7Sj9MByUgnhkgPrxd +um9guYhhaDUE7K3iATX6W1I/dW/rQ6dhZPVonyB4SuA/Pb3syKbefvY9p85fjaN3QUw /XluykUOdhltOTLuRhWKUDPMsEZLCH8dshkNNPFo8ho0bxofXyElFMQOK00b3Vn+jU83 GNOePnhFJDv3Pnmc0ehv+biNOtDWyPZXneQQ3Wf0yDFs05Xghffci5JpC3IHCD05UDxO pNoA== X-Received: by 10.229.173.202 with SMTP id q10mr6872143qcz.64.1374457179008; Sun, 21 Jul 2013 18:39:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Sun, 21 Jul 2013 18:38:58 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Sun, 21 Jul 2013 18:38:58 -0700 Message-ID: To: "Lijing (Jessie, Technology Introduction & Standard and Patent Dept)" Content-Type: multipart/alternative; boundary=001a1132eee6ea076904e20fbf2d X-Gm-Message-State: ALoCoQlEtUfs3ixwxwoyds8hNVADM58pVRSGJ2metgEQvBeoKUlRWN1iSvFxPzGDBRqlu7VZ8ojf Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] =?utf-8?b?562U5aSNOiBTb21lIHRob3VnaHRzIG9uIG9wdGlvbmFs?= =?utf-8?q?_audio_codecs?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 01:39:49 -0000 --001a1132eee6ea076904e20fbf2d Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 21, 2013 at 6:34 PM, Lijing (Jessie, Technology Introduction & Standard and Patent Dept) wrote: > I fully agree with the idea to " use existing "native" codecs ". > > In addition, from a web developer's perspective, in order to make use of > the "native" codecs, the browser should provide codec APIs to open the > local codec capabilities of the device to applications and developers. It > really make sense. > I don't understand what this means. -Ekr --001a1132eee6ea076904e20fbf2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 21, 2013 at 6:34 PM, Lijing (Jessie, Technolog= y Introduction & Standard and Patent Dept) <lijing80@huawei.com&= gt; wrote:
I fully agree with the idea to " use existing "native&q= uot; codecs ".

In addition, from a web developer's perspective, in order to make use o= f the "native" codecs, the browser should provide codec APIs to o= pen the local codec capabilities of the device to applications and develope= rs. It really make sense.

I don't understand what this means.

-Ekr
=A0
--001a1132eee6ea076904e20fbf2d-- From lijing80@huawei.com Sun Jul 21 20:42:33 2013 Return-Path: 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 9899421F9E6A for ; Sun, 21 Jul 2013 20:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-4.299, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 ABSRvq17uKR7 for ; Sun, 21 Jul 2013 20:42:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BA00F21F9D17 for ; Sun, 21 Jul 2013 20:42:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVG99590; Mon, 22 Jul 2013 03:42:23 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 04:41:31 +0100 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 04:42:20 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 11:42:17 +0800 From: "Lijing (Jessie, Technology Introduction & Standard and Patent Dept)" To: Eric Rescorla Thread-Topic: =?gb2312?B?W3J0Y3dlYl0gtPC4tDogU29tZSB0aG91Z2h0cyBvbiBvcHRpb25hbCBhdWRp?= =?gb2312?Q?o_codecs?= Thread-Index: Ac6BN11IugiIgzm2TXug3PomYB8N3AFQBe5g//+DcQD//3HGgA== Date: Mon, 22 Jul 2013 03:42:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.171.171] Content-Type: multipart/alternative; boundary="_000_A3045C90BB645147BC99159AA47ABAC7419F6161szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" Subject: [rtcweb] =?gb2312?b?tPC4tDogILTwuLQ6IFNvbWUgdGhvdWdodHMgb24gb3B0?= =?gb2312?b?aW9uYWwgYXVkaW8gY29kZWNz?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:42:33 -0000 --_000_A3045C90BB645147BC99159AA47ABAC7419F6161szxeml558mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U29ycnmjrEmhr3ZlIGNvbmZ1c2VkIHR3byBjb25jZXB0cy4gV2hhdCBJIHdhbnQgdG8gZXhwcmVz cyBpcyB0aGF0LA0KRmlyc3RseSwgdGhlIGJyb3dzZXIgbWF5IGJlIGFibGUgdG8gbWFrZSB1c2Ug b2YgobBuYXRpdmWhsSBjb2RlYyBBUElzIG9mIHRoZSChsGhhcmShsSBkZXZpY2UoZS5nLiBtb2Jp bGUgcGhvbmUpLCBhbmQgaW5jbHVkZSB0aGUgobBuYXRpdmWhsSBjb2RlY3MgaW4gdGhlIFNEUCBP L0EgbWVzc2FnZXMuDQpJbiBhZGRpdGlvbiwgZm9yIGFwcGxpY2F0aW9uIGZsZXhpYmlsaXR5LCB0 aGUgYnJvd3NlciBzaG91bGQgcHJvdmlkZSBjb2RlYyBjYXBhYmlsaXR5IEFQSXMgdG8gZGV2ZWxv cGVycy4gVGhlbiwgIHRoZSBkZXZlbG9wZXJzIGNhbiBjaG9vc2UgcHJvcGVyIGNvZGVjcyBhY2Nv cmRpbmcgdG8gdGhlIHNwZWNpZmljIHNjZW5hcmlvLg0KDQpTbyB0aGVyZSBzaG91bGQgYmUgdHdv IEFQSXMuIFRoZSBmaXJzdCBpcyBwcm92aWRlIGJ5IHRoZSBkZXZpY2UgYW5kIHVzZWQgYnkgdGhl IGJyb3dzZXIuIFRoZSBzZWNvbmQgaXMgcHJvdmlkZWQgYnkgdGhlIGJyb3dzZXIgYW5kIHVzZWQg YnkgdGhlIGRldmVsb3Blci4NCg0KQmVzdCBSZWdhcmRzLA0KTGlqaW5nDQoNCg0Kt6K8/sjLOiBF cmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0Kt6LLzcqxvOQ6IDIwMTPE6jfUwjIy yNUgOTozOQ0KytW8/sjLOiBMaWppbmcgKEplc3NpZSwgVGVjaG5vbG9neSBJbnRyb2R1Y3Rpb24g JiBTdGFuZGFyZCBhbmQgUGF0ZW50IERlcHQpDQqzrcvNOiBCbyBCdXJtYW47IHJ0Y3dlYkBpZXRm Lm9yZw0K1vfM4jogUmU6IFtydGN3ZWJdILTwuLQ6IFNvbWUgdGhvdWdodHMgb24gb3B0aW9uYWwg YXVkaW8gY29kZWNzDQoNCk9uIFN1biwgSnVsIDIxLCAyMDEzIGF0IDY6MzQgUE0sIExpamluZyAo SmVzc2llLCBUZWNobm9sb2d5IEludHJvZHVjdGlvbiAmIFN0YW5kYXJkIGFuZCBQYXRlbnQgRGVw dCkgPGxpamluZzgwQGh1YXdlaS5jb208bWFpbHRvOmxpamluZzgwQGh1YXdlaS5jb20+PiB3cm90 ZToNCkkgZnVsbHkgYWdyZWUgd2l0aCB0aGUgaWRlYSB0byAiIHVzZSBleGlzdGluZyAibmF0aXZl IiBjb2RlY3MgIi4NCg0KSW4gYWRkaXRpb24sIGZyb20gYSB3ZWIgZGV2ZWxvcGVyJ3MgcGVyc3Bl Y3RpdmUsIGluIG9yZGVyIHRvIG1ha2UgdXNlIG9mIHRoZSAibmF0aXZlIiBjb2RlY3MsIHRoZSBi cm93c2VyIHNob3VsZCBwcm92aWRlIGNvZGVjIEFQSXMgdG8gb3BlbiB0aGUgbG9jYWwgY29kZWMg Y2FwYWJpbGl0aWVzIG9mIHRoZSBkZXZpY2UgdG8gYXBwbGljYXRpb25zIGFuZCBkZXZlbG9wZXJz LiBJdCByZWFsbHkgbWFrZSBzZW5zZS4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBt ZWFucy4NCg0KLUVrcg0KDQo= --_000_A3045C90BB645147BC99159AA47ABAC7419F6161szxeml558mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Sorry=A3=ACI=A1=AFve confused two concepts. What I want to express is that,

Firstly, t= he browser may be able to make use of =A1=B0native=A1=B1 codec APIs of the = =A1=B0hard=A1=B1 device(e.g. mobile phone), and include the =A1=B0native=A1= =B1 codecs in the SDP O/A messages.

In additio= n, for application flexibility, the browser should provide codec capability= APIs to developers. Then,  the developers can choose proper codecs according to the specific scenario.

 = ;

So there s= hould be two APIs. The first is provide by the device and used by the brows= er. The second is provided by the browser and used by the developer.

 = ;

Best Regar= ds,

Lijing

 = ;

 = ;

=B7=A2=BC=FE=C8= =CB: Eric Rescorla [mailto:ekr@rtfm.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C222=C8=D5 9= :39
=CA=D5=BC=FE=C8=CB: Lijing (Jessie, Technology Introduction & Standard and Patent D= ept)
=B3=AD=CB=CD: Bo Burman; rtcweb@ietf.org
=D6=F7=CC=E2: Re: [rtcweb] =B4=F0=B8=B4: Some thoughts on optional audio codecs

 

On Sun, Jul 21, 2013 at 6:34 PM= , Lijing (Jessie, Technology Introduction & Standard and Patent Dept) &= lt;lijing80@huawei= .com> wrote:

I fully agree with the idea to = " use existing "native" codecs ".

In addition, from a web developer's perspective, in order to make use of th= e "native" codecs, the browser should provide codec APIs to open = the local codec capabilities of the device to applications and developers. = It really make sense.

 

I don't understand what this me= ans.

 

-Ekr

 

--_000_A3045C90BB645147BC99159AA47ABAC7419F6161szxeml558mbschi_-- From ekr@rtfm.com Sun Jul 21 20:47:45 2013 Return-Path: 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 B2BD421F9EDF for ; Sun, 21 Jul 2013 20:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.729 X-Spam-Level: X-Spam-Status: No, score=-98.729 tagged_above=-999 required=5 tests=[AWL=-3.048, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 3kyi7BNkRFDT for ; Sun, 21 Jul 2013 20:47:39 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4276A21F9D56 for ; Sun, 21 Jul 2013 20:47:39 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so3388744qcx.35 for ; Sun, 21 Jul 2013 20:47:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=rS60u4B/xRx+fBFzBngIwXxe410lBa331tgeToafY/w=; b=ZFJPpomX385/k8UceGu0sYUNTP4XCRxxgb/8gpn6T5C2PeC/UUtKWa67fkm2w+o3hU kVDo7Ha/bVHj3MRWTLAmBLWg+dXR+2Z69qEALUO7hUlyNiDj8mHSx0vaSktv9gdV4+zR Gtbh4O3McA65P+PHAa0/6xsdFWAwkdiBieS6ldkNtFkqSZVnBTzupEJVq/Z2MAd82jbG EgqdM1J4gY/tQ5TRiFbnAVP9dxJEhbKAADpkRs8J0w2msATke9QqvhrBLZcowmb7zVo2 F9lY9/CkesXGqgNNlTDxPfQ6SU+c5GvsA5ieEbHmGfyND13BNEf4qYlsrzjFSFlZW46d vmzw== X-Received: by 10.224.223.202 with SMTP id il10mr18600696qab.87.1374464857689; Sun, 21 Jul 2013 20:47:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Sun, 21 Jul 2013 20:46:57 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 21 Jul 2013 20:46:57 -0700 Message-ID: To: "Lijing (Jessie, Technology Introduction & Standard and Patent Dept)" Content-Type: multipart/alternative; boundary=001a11c2318e99621504e2118958 X-Gm-Message-State: ALoCoQnlm0tJIqxHiKtVHWSkUQ8UgWV2ZlR5pJ0epocVZPXfPEGCPOztZLpM+daGju99m72qS4C5 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] =?gb2312?b?tPC4tDogILTwuLQ6IFNvbWUgdGhvdWdodHMgb24gb3B0?= =?gb2312?b?aW9uYWwgYXVkaW8gY29kZWNz?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:47:46 -0000 --001a11c2318e99621504e2118958 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Sun, Jul 21, 2013 at 8:42 PM, Lijing (Jessie, Technology Introduction & Standard and Patent Dept) wrote: > Sorry=A3=ACI=A1=AFve confused two concepts. What I want to express is th= at,**** > > Firstly, the browser may be able to make use of =A1=B0native=A1=B1 codec = APIs of the > =A1=B0hard=A1=B1 device(e.g. mobile phone), and include the =A1=B0native= =A1=B1 codecs in the > SDP O/A messages.**** > > In addition, for application flexibility, the browser should provide code= c > capability APIs to developers. Then, the developers can choose proper > codecs according to the specific scenario. **** > > ** ** > > So there should be two APIs. The first is provide by the device and used > by the browser. > Well, devices may or may not do this, but that's kind of out of scope for this WG. The second is provided by the browser and used by the developer. > Yes, this seems not unreasonable... -Ekr --001a11c2318e99621504e2118958 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable



On Sun, Jul 21, 2013 at 8:42 PM, Lijing (Jessie, Technology Introdu= ction & Standard and Patent Dept) <lijing80@huawei.com> wrote:

Sorry=A3=ACI’ve confused two concepts. What I want to express is that,

Firstly, t= he browser may be able to make use of “native” codec APIs of th= e “hard” device(e.g. mobile phone), and include the “nati= ve” codecs in the SDP O/A messages.

In additio= n, for application flexibility, the browser should provide codec capability= APIs to developers. Then,  the developers can choose proper codecs according to the specific scenario.

&nb= sp;

So there s= hould be two APIs. The first is provide by the device and used by the brows= er.


Well, devices may or may not d= o this, but that's kind of out of scope for
this WG.


The second is provided by the= browser and used by the developer.


Yes, thi= s seems not unreasonable...

-Ekr
 <= /div>
--001a11c2318e99621504e2118958-- From tireddy@cisco.com Mon Jul 22 05:53:54 2013 Return-Path: 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 25E2911E8101; Mon, 22 Jul 2013 05:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 dMvUaTygEjDb; Mon, 22 Jul 2013 05:53:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B372111E80D5; Mon, 22 Jul 2013 05:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16328; q=dns/txt; s=iport; t=1374497628; x=1375707228; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DS4BgToDvmWpXeDOeTHhcHlWSodOgS93fVmyfGSnsDU=; b=H+tjn9r/Ug2g2qBKOOZOa492c8VD9XAEj7fGvSRmUFnpecTkxg9c09cX g92WGxlfmk/KkJ3qCWTzoYWhLB41KJGl4fxWAtxpHJlKNdgl61Y2+35Rm Z+74rjw7rKA6LxExaP7AaaekNw55+I70LJPx2L9gAoySPvsyECFhI76ET 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFAIoq7VGtJV2b/2dsb2JhbABagkJENVCDCqs2iTeIORd3FnSCJAEBAQQjCkEJAhACAQgOAwMBAQELHQMCAgIwFAkIAgQOBQgBiAcMphGRFY5egQcgEQYBBoJXM24DmQaQJIFZgTmBaCICHg X-IronPort-AV: E=Sophos;i="4.89,719,1367971200"; d="scan'208,217";a="234787165" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2013 12:53:48 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6MCrlRr011792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 12:53:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 07:53:47 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt Thread-Index: AQHOgaXFxG8B2qhG1UKzVBv1DFSHsZlvKhOQ Date: Mon, 22 Jul 2013 12:53:47 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9F74D@xmb-rcd-x10.cisco.com> References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.58] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B9F74Dxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 12:53:54 -0000 --_000_913383AAA69FF945B8F946018B75898A14B9F74Dxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpZb3UgbWF5IGFsc28gd2FudCB0byBjb25zaWRlciB5b3VyIHVzaW5nIE9B dXRoIDIuMCBmcmFtZXdvcmsuIEZvciBleGFtcGxlIGNvbnNpZGVyIGRyYWZ0IChodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLWh0dHAtbWFjLTA0I3NlY3Rpb24t Ni4xKSBXaGVyZSBXZWJTZXJ2ZXIgd291bGQgYWN0IGFzIEF1dGhvcml6YXRpb24gU2VydmVyIChB UyksIFRVUk4gU2VydmVyIGFzIFJlc291cmNlIFNlcnZlciAoUlMpIGFuZCBDbGllbnQgd2lsbCBi ZSB0aGUgV2ViUlRDIENsaWVudC4NCg0KVGhlIGFkdmFudGFnZSBvZiB1c2luZyBPQXV0aCBpcyB0 aGF0DQoNClsxXSBJZiBoYW5kbGUgdG9rZW4gaXMgY2hvc2VuLCBBUyBjYW4gcmV2b2tlIHRoZSBj cmVkZW50aWFscyBhZnRlciB0aGUgY2FsbCBpcyB0ZXJtaW5hdGVkLiBUaGlzIHdvdWxkIGVuc3Vy ZSB0aGF0IGV2ZW4gaWYgdGhlIHRlbXBvcmFyeSBjcmVkZW50aWFscyBhcmUgZXhwb3NlZCB0byBK YXZhU2NyaXB0LCB0aGVzZSBjcmVkZW50aWFscyBjYW4gYmUgb25seSB1c2VkIGZvciB0aGUgZHVy YXRpb24gb2YgdGhlIGNhbGwuIFRoaXMgd291bGQgcHJldmVudCBhbnkgYXR0YWNrcyBwb3NzaWJs ZSBvZiBzb21lb25lIGVsc2UgdXNpbmcgdGhlIHRlbXBvcmFyeSBjcmVkZW50aWFscyBldmVuIGFm dGVyIHRoZSBjYWxsIGlzIHRlcm1pbmF0ZWQuDQoNClsyXSBBUyBhbmQgUlMgbmVlZCB0byBub3Qg YmUgY28tbG9jYXRlZC4NCg0KWzNdIEFTIGFuZCBSUyBuZWVkIG5vdCB1c2Ugc3RhdGljIHNoYXJl ZCBzZWNyZXQ7IE9BdXRoIHByb3ZpZGVzIGZsZXhpYmlsaXR5IGZvciB0aGUgQVMgdG8gdXBkYXRl IHRoZSBSUyB3aXRoIHNlc3Npb24ga2V5cy4NCg0KWzRdIEkgYmVsaWV2ZSB0aGVyZSBhcmUgYWxy ZWFkeSBpbXBsZW1lbnRhdGlvbnMgYXZhaWxhYmxlIG9mIE9BdXRoLg0KDQpCZXN0IFJlZ2FyZHMs DQotLVRpcnUuDQpGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogVHVlc2Rh eSwgSnVseSAxNiwgMjAxMyAzOjIzIEFNDQpUbzogcnRjd2ViQGlldGYub3JnOyBiZWhhdmVAaWV0 Zi5vcmcNClN1YmplY3Q6IFtydGN3ZWJdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVzdC0wMC50eHQNCg0KSSBoYXZlIGNoYW5nZWQg dGhlIFdHIGZvciB0aGlzIGRyYWZ0IGZyb20gUlRDV0VCIHRvIEJFSEFWRS4gTWFueSwgYnV0IG5v dCBhbGwgb2YgdGhlIGNvbW1lbnRzIEkgcmVjZWl2ZWQgb24gdGhlIFJUQ1dFQiBtYWlsaW5nIGxp c3QgaGF2ZSBiZWVuIGFkZHJlc3NlZC4NCg0KQkVIQVZFIGNoYWlycywgSSB3b3VsZCBsaWtlIDEw IG1pbnV0ZXMgb2YgYWdlbmRhIHRpbWUgdG8gZGlzY3VzcyB0aGlzIGRyYWZ0Lg0KLS0tLS0tLS0t LSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uLCBKdWwg MTUsIDIwMTMgYXQgNTo0OSBQTQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVzdC0wMC50eHQNClRvOiBKdXN0aW4gVWJlcnRp IDxqdXN0aW5AdWJlcnRpLm5hbWU8bWFpbHRvOmp1c3RpbkB1YmVydGkubmFtZT4+DQoNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdWJlcnRpLWJlaGF2ZS10dXJuLXJlc3QtMDAudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEp1c3RpbiBVYmVydGkgYW5kIHBv c3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC11 YmVydGktYmVoYXZlLXR1cm4tcmVzdA0KUmV2aXNpb246ICAgICAgICAwMA0KVGl0bGU6ICAgICAg ICAgICBBIFJFU1QgQVBJIEZvciBBY2Nlc3MgVG8gVFVSTiBTZXJ2aWNlcw0KQ3JlYXRpb24gZGF0 ZTogICAyMDEzLTA3LTE1DQpHcm91cDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K TnVtYmVyIG9mIHBhZ2VzOiA4DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXViZXJ0aS1iZWhhdmUtdHVybi1yZXN0LTAwLnR4dA0KU3Rh dHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXViZXJ0 aS1iZWhhdmUtdHVybi1yZXN0DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXViZXJ0aS1iZWhhdmUtdHVybi1yZXN0LTAwDQoNCg0KQWJzdHJhY3Q6DQog ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHByb3Bvc2VkIHN0YW5kYXJkIFJFU1QgQVBJIGZv ciBvYnRhaW5pbmcNCiAgIGFjY2VzcyB0byBUVVJOIHNlcnZpY2VzIHZpYSBlcGhlbWVyYWwgKGku ZS4gdGltZS1saW1pdGVkKQ0KICAgY3JlZGVudGlhbHMuICBUaGVzZSBjcmVkZW50aWFscyBhcmUg dmVuZGVkIGJ5IGEgd2ViIHNlcnZpY2Ugb3Zlcg0KICAgSFRUUCwgYW5kIHRoZW4gc3VwcGxpZWQg dG8gYW5kIGNoZWNrZWQgYnkgYSBUVVJOIHNlcnZlciB1c2luZyB0aGUNCiAgIHN0YW5kYXJkIFRV Uk4gcHJvdG9jb2wuICBUaGUgdXNhZ2Ugb2YgZXBoZW1lcmFsIGNyZWRlbnRpYWxzIGVuc3VyZXMN CiAgIHRoYXQgYWNjZXNzIHRvIHRoZSBUVVJOIHNlcnZlciBjYW4gYmUgY29udHJvbGxlZCBldmVu IGlmIHRoZQ0KICAgY3JlZGVudGlhbHMgY2FuIGJlIGRpc2NvdmVyZWQgYnkgdGhlIHVzZXIsIGFz IGlzIHRoZSBjYXNlIGluIFdlYlJUQw0KICAgd2hlcmUgVFVSTiBjcmVkZW50aWFscyBtdXN0IGJl IHNwZWNpZmllZCBpbiBKYXZhc2NyaXB0Lg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQoNCg== --_000_913383AAA69FF945B8F946018B75898A14B9F74Dxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQot LT4NCjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SGkgSnVzdGluLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPllvdSBtYXkgYWxzbyB3YW50IHRvIGNvbnNpZGVyIHlvdXIgdXNpbmcgT0F1dGgg Mi4wIGZyYW1ld29yay4gRm9yIGV4YW1wbGUgY29uc2lkZXIgZHJhZnQgKDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItaHR0cC1tYWMtMDQjc2Vj dGlvbi02LjEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjIt aHR0cC1tYWMtMDQjc2VjdGlvbi02LjE8L2E+KQ0KIFdoZXJlIFdlYlNlcnZlciB3b3VsZCBhY3Qg YXMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgKEFTKSwgVFVSTiBTZXJ2ZXIgYXMgUmVzb3VyY2UgU2Vy dmVyIChSUykgYW5kIENsaWVudCB3aWxsIGJlIHRoZSBXZWJSVEMgQ2xpZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5 N0QiPlRoZSBhZHZhbnRhZ2Ugb2YgdXNpbmcgT0F1dGggaXMgdGhhdA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ WzFdIElmIGhhbmRsZSB0b2tlbiBpcyBjaG9zZW4sIEFTIGNhbiByZXZva2UgdGhlIGNyZWRlbnRp YWxzIGFmdGVyIHRoZSBjYWxsIGlzIHRlcm1pbmF0ZWQuIFRoaXMgd291bGQgZW5zdXJlIHRoYXQg ZXZlbiBpZiB0aGUgdGVtcG9yYXJ5IGNyZWRlbnRpYWxzIGFyZSBleHBvc2VkDQogdG8gSmF2YVNj cmlwdCwgdGhlc2UgY3JlZGVudGlhbHMgY2FuIGJlIG9ubHkgdXNlZCBmb3IgdGhlIGR1cmF0aW9u IG9mIHRoZSBjYWxsLiBUaGlzIHdvdWxkIHByZXZlbnQgYW55IGF0dGFja3MgcG9zc2libGUgb2Yg c29tZW9uZSBlbHNlIHVzaW5nIHRoZSB0ZW1wb3JhcnkgY3JlZGVudGlhbHMgZXZlbiBhZnRlciB0 aGUgY2FsbCBpcyB0ZXJtaW5hdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlsyXSBBUyBhbmQgUlMgbmVlZCB0 byBub3QgYmUgY28tbG9jYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5bM10gQVMgYW5kIFJTIG5lZWQgbm90 IHVzZSBzdGF0aWMgc2hhcmVkIHNlY3JldDsgT0F1dGggcHJvdmlkZXMgZmxleGliaWxpdHkgZm9y IHRoZSBBUyB0byB1cGRhdGUgdGhlIFJTIHdpdGggc2Vzc2lvbiBrZXlzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi Pls0XSBJIGJlbGlldmUgdGhlcmUgYXJlIGFscmVhZHkgaW1wbGVtZW50YXRpb25zIGF2YWlsYWJs ZSBvZiBPQXV0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+LS1UaXJ1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3Rp biBVYmVydGk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxNiwgMjAxMyAzOjIzIEFN PGJyPg0KPGI+VG86PC9iPiBydGN3ZWJAaWV0Zi5vcmc7IGJlaGF2ZUBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBbcnRjd2ViXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtdWJlcnRpLWJlaGF2ZS10dXJuLXJlc3QtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBjaGFuZ2VkIHRoZSBXRyBm b3IgdGhpcyBkcmFmdCBmcm9tIFJUQ1dFQiB0byBCRUhBVkUuIE1hbnksIGJ1dCBub3QgYWxsIG9m IHRoZSBjb21tZW50cyBJIHJlY2VpdmVkIG9uIHRoZSBSVENXRUIgbWFpbGluZyBsaXN0IGhhdmUg YmVlbiBhZGRyZXNzZWQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5CRUhBVkUgY2hhaXJzLCBJIHdvdWxkIGxpa2UgMTAg bWludXRlcyBvZiBhZ2VuZGEgdGltZSB0byBkaXNjdXNzIHRoaXMgZHJhZnQuPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRGF0ZTogTW9uLCBKdWwg MTUsIDIwMTMgYXQgNTo0OSBQTTxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtdWJlcnRpLWJlaGF2ZS10dXJuLXJlc3QtMDAudHh0PGJyPg0KVG86IEp1c3Rp biBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdXN0aW5AdWJlcnRpLm5hbWUiIHRhcmdldD0i X2JsYW5rIj5qdXN0aW5AdWJlcnRpLm5hbWU8L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4N CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVzdC0wMC50 eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEp1c3RpbiBVYmVydGkg YW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KRmlsZW5h bWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXViZXJ0aS1iZWhhdmUtdHVybi1y ZXN0PGJyPg0KUmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAwPGJyPg0KVGl0 bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQSBSRVNUIEFQSSBGb3IgQWNj ZXNzIFRvIFRVUk4gU2VydmljZXM8YnI+DQpDcmVhdGlvbiBkYXRlOiAmbmJzcDsgMjAxMy0wNy0x NTxicj4NCkdyb3VwOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1 YWwgU3VibWlzc2lvbjxicj4NCk51bWJlciBvZiBwYWdlczogODxicj4NClVSTDogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdWJlcnRpLWJlaGF2ZS10dXJuLXJlc3QtMDAudHh0 IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVzdC0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVzdCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdWJlcnRpLWJlaGF2ZS10 dXJuLXJlc3Q8L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXViZXJ0aS1iZWhhdmUtdHVy bi1yZXN0LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtdWJlcnRpLWJlaGF2ZS10dXJuLXJlc3QtMDA8L2E+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJh Y3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcHJvcG9zZWQg c3RhbmRhcmQgUkVTVCBBUEkgZm9yIG9idGFpbmluZzxicj4NCiZuYnNwOyAmbmJzcDthY2Nlc3Mg dG8gVFVSTiBzZXJ2aWNlcyB2aWEgZXBoZW1lcmFsIChpLmUuIHRpbWUtbGltaXRlZCk8YnI+DQom bmJzcDsgJm5ic3A7Y3JlZGVudGlhbHMuICZuYnNwO1RoZXNlIGNyZWRlbnRpYWxzIGFyZSB2ZW5k ZWQgYnkgYSB3ZWIgc2VydmljZSBvdmVyPGJyPg0KJm5ic3A7ICZuYnNwO0hUVFAsIGFuZCB0aGVu IHN1cHBsaWVkIHRvIGFuZCBjaGVja2VkIGJ5IGEgVFVSTiBzZXJ2ZXIgdXNpbmcgdGhlPGJyPg0K Jm5ic3A7ICZuYnNwO3N0YW5kYXJkIFRVUk4gcHJvdG9jb2wuICZuYnNwO1RoZSB1c2FnZSBvZiBl cGhlbWVyYWwgY3JlZGVudGlhbHMgZW5zdXJlczxicj4NCiZuYnNwOyAmbmJzcDt0aGF0IGFjY2Vz cyB0byB0aGUgVFVSTiBzZXJ2ZXIgY2FuIGJlIGNvbnRyb2xsZWQgZXZlbiBpZiB0aGU8YnI+DQom bmJzcDsgJm5ic3A7Y3JlZGVudGlhbHMgY2FuIGJlIGRpc2NvdmVyZWQgYnkgdGhlIHVzZXIsIGFz IGlzIHRoZSBjYXNlIGluIFdlYlJUQzxicj4NCiZuYnNwOyAmbmJzcDt3aGVyZSBUVVJOIGNyZWRl bnRpYWxzIG11c3QgYmUgc3BlY2lmaWVkIGluIEphdmFzY3JpcHQuPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A14B9F74Dxmbrcdx10ciscoc_-- From stephane.proust@orange.com Mon Jul 22 07:58:08 2013 Return-Path: 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 AC8B321F9970 for ; Mon, 22 Jul 2013 07:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 Eqcil2JTY8K8 for ; Mon, 22 Jul 2013 07:58:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7B94411E80F6 for ; Mon, 22 Jul 2013 07:57:51 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 84A393B4E1C; Mon, 22 Jul 2013 16:57:49 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 57AFF4C060; Mon, 22 Jul 2013 16:57:49 +0200 (CEST) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 16:57:48 +0200 From: To: '???/Lingli Deng' , 'Paul Coverdale' , "'Hutton, Andrew'" , "'Bogineni, Kalyani'" , 'Bo Burman' , "'rtcweb@ietf.org'" Thread-Topic: [rtcweb] Some thoughts on optional audio codecs Thread-Index: Ac6G62PsbuoNXlIuRQ+5I6swshBWMg== Date: Mon, 22 Jul 2013 14:57:48 +0000 Message-ID: <24444_1374505069_51ED486D_24444_498_4_2842AD9A45C83B44B57635FD4831E60A06C2EE3A@PEXCVZYM14.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Subject: Re: [rtcweb] Some thoughts on optional audio codecs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 14:58:09 -0000 SXQgd291bGQgYmUgZ29vZCB0byBjbG9zZSB0aGlzIHZvaWNlL2F1ZGlvIGNvZGVjcyB0b3BpYyB3 aXRoIGFuIGFncmVlYWJsZSBtaW5pbXVtICJjb25jbHVzaW9uIHN0YXRlbWVudCIgDQoNCk15IHJl Y29sbGVjdGlvbiBpcyB0aGF0IHRoZSBwcm9wb3NlZCBzdGF0ZW1lbnQgaXMgZXhhY3RseSB0aGUg Y29tcHJvbWlzZSBzdGF0ZW1lbnQgdGhhdCB3YXMgYWxtb3N0IHJlYWNoZWQgaW4gZS1tYWlsIGRp c2N1c3Npb25zIGxhc3QgSmFudWFyeSAoZnJvbSBhbiBpbml0aWFsIHByb3Bvc2FsIGZyb20gQW5k cmV3IEFsbGVuKSANCg0KPj4gIklmIG90aGVyIHN1aXRhYmxlIGF1ZGlvIGNvZGVjcyBhcmUgYXZh aWxhYmxlIHRvIHRoZSBicm93c2VyIHRvIHVzZSwgDQo+PiBpdCBpcyByZWNvbW1lbmRlZCB0aGF0 IHRoZXkgYXJlIGFsc28gaW5jbHVkZWQgaW4gdGhlIG9mZmVyIGluIG9yZGVyIA0KPj4gdG8gbWF4 aW1pemUgdGhlIHBvc3NpYmlsaXR5IHRvIGVzdGFibGlzaCB0aGUgc2Vzc2lvbiB3aXRob3V0IHRo ZSBuZWVkIA0KPj4gZm9yIGF1ZGlvIHRyYW5zY29kaW5nIi4NCg0KVGhpcyBjYW1lIGFsb25nIHdp dGggdGhlIGNvbmNsdXNpb24gZnJvbSB0aGUgQ2hhaXJzIHRoYXQgaXQgd291bGQgYmUgb2YgaW50 ZXJlc3QgdG8gaGF2ZSBzb21lIGFkZGl0aW9uYWwgaW5mb3JtYXRpdmUgdGV4dCBhYm91dCB3aGF0 IGFyZSB0aG9zZSBzdWl0YWJsZSBjb2RlY3MgdG8gYmUgY29uc2lkZXJlZCBhbmQgd2hhdCBpcyB0 aGUgcmF0aW9uYWxlIGJlaGluZCB0aGlzLg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzA2MTY3Lmh0bWwNCg0KU28sIGlmIHRoaXMgaXMgdGhl IHdheSB0byBtb3ZlIGZvcndhcmQgYW5kIG1ha2UgYXQgbGVhc3Qgb25lIHNtYWxsIHN0ZXAgdG8g Y29uY2x1ZGUgc29tZXRoaW5nLCB5ZXMgdGhpcyBzb3VuZHMgcmVhc29uYWJsZSBhbmQgSSBzdXBw b3J0IHRoaXMuDQoNClN0w6lwaGFuZQ0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRl wqA6IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmddIERlIGxhIHBhcnQgZGUgPz8/L0xpbmdsaSBEZW5nDQpFbnZvecOpwqA6IHZlbmRyZWRpIDE5 IGp1aWxsZXQgMjAxMyAwNzozNA0Kw4DCoDogJ1BhdWwgQ292ZXJkYWxlJzsgJ0h1dHRvbiwgQW5k cmV3JzsgJ0JvZ2luZW5pLCBLYWx5YW5pJzsgJ0JvIEJ1cm1hbic7IHJ0Y3dlYkBpZXRmLm9yZw0K T2JqZXTCoDogW3J0Y3dlYl0g562U5aSNOiBTb21lIHRob3VnaHRzIG9uIG9wdGlvbmFsIGF1ZGlv IGNvZGVjcw0KDQpXZSBhbHNvIHN1cHBvcnQgdGhpcyBwcm9wb3NhbC4NCg0KSW4gcGFydGljdWxh ciwgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBhbGxvdyB0aGUgY29kZWMgY2hvaWNlIGJlIHBv c3NpYmx5IGRlbGVnYXRlZCB0byBpbmRpdmlkdWFsIHdlYiBkZXZlbG9wZXJzIG1ha2luZyB1c2Ug b2YgV2ViUlRDIGZ1bmN0aW9uYWxpdHkuDQpUaGVyZWZvcmUsIGl0IHdvdWxkIGJlIGJldHRlciBm b3IgdGhlbSB0byBiZSBpbmZvcm1lZCBvZiBhdmFpbGFibGUgb3B0aW9ucyBhbmQgbWFrZSB0aGUg ZGVjaXNpb24gYWNjb3JkaW5nbHkuDQpXaGlsZSBpdCBpcyBub3QgcmVhbGlzdGljIHRvIGFzc3Vt ZSB0aGF0IGEgYnJvd3NlciBjb3VsZCBhbHdheXMgaW1wbGVtZW50IGEgYmVzdCBjaG9pY2UgZm9y IGV2ZXJ5IHBvdGVudGlhbCBzZXR0aW5nLCB0byBpbmNsdWRlIG90aGVyIGF2YWlsYWJsZSBjb2Rl YyBpbiB0aGUgb2ZmZXIgd291bGQgb3BlbiB0aGUgZG9vciB0byBhIHdpbi13aW4gb3V0Y29tZS4N Cg0KQlINCkxpbmdsaQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IHJ0Y3dl Yi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ih qCBQYXVsIENvdmVyZGFsZQ0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0N+aciDE45pelIDIwOjI1DQrm lLbku7bkuro6ICdIdXR0b24sIEFuZHJldyc7ICdCb2dpbmVuaSwgS2FseWFuaSc7ICdCbyBCdXJt YW4nOyBydGN3ZWJAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtydGN3ZWJdIFNvbWUgdGhvdWdodHMg b24gb3B0aW9uYWwgYXVkaW8gY29kZWNzDQoNClllcywgdGhpcyB0ZXh0IGhhcyBiZWVuIGFyb3Vu ZCBmb3IgYSB3aGlsZS4gSSBhbHNvIHN1cHBvcnQgaXQuDQoNCi4uLlBhdWwNCg0KPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+QmVoYWxmIE9mIEh1dHRvbiwgQW5kcmV3 DQo+U2VudDogV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDEzIDQ6NDYgQU0NCj5UbzogQm9naW5lbmks IEthbHlhbmk7ICdCbyBCdXJtYW4nOyBydGN3ZWJAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3J0 Y3dlYl0gU29tZSB0aG91Z2h0cyBvbiBvcHRpb25hbCBhdWRpbyBjb2RlY3MNCj4NCj5XZSBhcHBl YXIgdG8gaGF2ZSBiZWVuIGFyb3VuZCB0aGlzIGxvb3AgYSBudW1iZXIgb2YgdGltZXMgdGhlIHRl eHQgDQo+c3VnZ2VzdGVkIGhlcmUgaXMgZXhhY3RseSB3aGF0IHdhcyBzdWdnZXN0ZWQgYnkgQW5k cmV3IEFsbGVuIGJhY2sgaW4gDQo+SmFudWFyeSBhbmQgSSBmb3Igb25lIHN1cHBvcnRlZCBpdCB0 aGVtIGFuZCBzdGlsbCBkbyAtIFNlZSANCj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMDYxMjEuaHRtbC4NCj4NCj5Ob3Qgc3VyZSB0aGVyZSB3 YXMgYSBkZWZpbml0aXZlIGNvbmNsdXNpb24gdG8gdGhhdCBwYXJ0aWN1bGFyIGNvbnNlbnN1cyAN Cj5jYWxsLg0KPg0KPkFuZHkNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ PiBGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXSBPbiANCj4+IEJlaGFsZiBPZiBCb2dpbmVuaSwgS2FseWFuaQ0KPj4gU2VudDogMTYg SnVseSAyMDEzIDE4OjAyDQo+PiBUbzogJ0JvIEJ1cm1hbic7IHJ0Y3dlYkBpZXRmLm9yZw0KPj4g Q2M6IEJvZ2luZW5pLCBLYWx5YW5pDQo+PiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gU29tZSB0aG91 Z2h0cyBvbiBvcHRpb25hbCBhdWRpbyBjb2RlY3MNCj4+DQo+PiBXZSBzdXBwb3J0IHRoZSBmb2xs b3dpbmcgd29yZGluZyBwcm9wb3NhbCBmcm9tIEJvIEJ1cm1hbi4NCj4+DQo+PiAiSWYgb3RoZXIg c3VpdGFibGUgYXVkaW8gY29kZWNzIGFyZSBhdmFpbGFibGUgdG8gdGhlIGJyb3dzZXIgdG8gdXNl LCANCj4+IGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhleSBhcmUgYWxzbyBpbmNsdWRlZCBpbiB0 aGUgb2ZmZXIgaW4gb3JkZXIgDQo+PiB0byBtYXhpbWl6ZSB0aGUgcG9zc2liaWxpdHkgdG8gZXN0 YWJsaXNoIHRoZSBzZXNzaW9uIHdpdGhvdXQgdGhlIG5lZWQgDQo+PiBmb3IgYXVkaW8gdHJhbnNj b2RpbmciLg0KPj4NCj4+IFJlZ2FyZHMsDQo+PiBLYWx5YW5pIEJvZ2luZW5pDQo+PiBWZXJpem9u DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4gQmVo YWxmIE9mIEJvIEJ1cm1hbg0KPj4gU2VudDogTW9uZGF5LCBKdWx5IDE1LCAyMDEzIDExOjE1IEFN DQo+PiBUbzogcnRjd2ViQGlldGYub3JnDQo+PiBTdWJqZWN0OiBbcnRjd2ViXSBTb21lIHRob3Vn aHRzIG9uIG9wdGlvbmFsIGF1ZGlvIGNvZGVjcw0KPj4NCj4+IFJlZ2FyZGluZyB0aGUgcHJldmlv dXMgZGlzY3Vzc2lvbiBvbiBvcHRpb25hbCBhdWRpbyBjb2RlY3MgaW4gdGhlIA0KPj4gKGN1cnJl bnRseSBleHBpcmVkKSBkcmFmdCBvbiBSVENXRUIgYXVkaW8gY29kZWNzDQo+PiAoaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8vKToNCj4+DQo+ PiBJIHRoaW5rIG1vc3QgcGFydGllcyBpbnZvbHZlZCBpbiBXZWJSVEMgd29yaywgbXlzZWxmIGlu Y2x1ZGVkLCBob3BlIA0KPj4gYW5kIGJlbGlldmUgdGhhdCBpdCB3aWxsIGJlIHViaXF1aXRvdXMg YW5kIGVhc3kgdG8gaW5jbHVkZSByZWFsLXRpbWUgDQo+PiBtZWRpYSBjb252ZXJzYXRpb24gZnVu Y3Rpb25hbGl0eSBpbiBuZWFybHkgYW55IHdlYiBjb250ZXh0LiBTaW5jZSBpdCANCj4+IHdpbGwg YmUgdGhhdCBlYXN5LCBpdCBjYW4gYmUgZXhwZWN0ZWQgdGhhdCBtb3N0IHdlYiBkZXZlbG9wZXJz IG5lZWQgDQo+PiBub3QgYmUsIGFuZCB0aHVzIHdpbGwgbm90IGJlLCBtZWRpYSBzcGVjaWFsaXN0 cyBvciB2ZXJ5IGtub3dsZWRnZWFibGUNCj5hYm91dCBjb2RlY3MuDQo+Pg0KPj4gVGhlIGRlZmlu aXRpb24gb2YgUlRDV0VCIE1USSBjb2RlY3MgZW5zdXJlcyB0aGF0IGNvbW11bmljYXRpb24gaXMg DQo+PiBwb3NzaWJsZSBzaW5jZSBhdCBsZWFzdCBvbmUgY29kZWMgd2lsbCBhbHdheXMgYmUgZm91 bmQsIGJ1dCBpdCBpcyBub3QgDQo+PiBwb3NzaWJsZSB0byBjbGFpbSB0aGUgcmVzdWx0aW5nIGNv bW11bmljYXRpb24gdG8gYmUgb3B0aW11bSBmb3IgZXZlcnkgDQo+PiBwb3NzaWJsZSBjb250ZXh0 Lg0KPj4NCj4+IEV2ZW4gaWYgV2ViUlRDIHdpbGwgYmUgY2xvc2UgdG8gdWJpcXVpdG91cywgdGhl cmUgd2lsbCBmb3IgcXVpdGUgc29tZSANCj4+IHRpbWUgbGlrZWx5IGJlIGEgZGVzaXJlIHRvIHJl YWNoIHJlYWwtdGltZSBtZWRpYSBkb21haW5zIGFuZCBkZXZpY2VzIA0KPj4gdGhhdCB3ZXJlIG5v dCBvcmlnaW5hbGx5IGRlc2lnbmVkIGZvciBhbmQgdGh1cyBhcmUgbm90IG9wdGltaXplZCBmb3Ig DQo+PiB1c2Ugd2l0aCBXZWJSVEMuIEEgY29tbXVuaWNhdGlvbiBkZXZpY2UgdGhhdCBpcyBub3Qg ZGVzaWduZWQgc29sZWx5IA0KPj4gZm9yIFdlYlJUQyB1c2Ugd2lsbCBsaWtlbHkgaW5jbHVkZSBm dW5jdGlvbmFsaXR5IGFuZCBjb2RlY3MgYWxzbyBmb3IgDQo+PiBpdHMgIm5hdGl2ZSIgZG9tYWlu Lg0KPj4NCj4+IEFueSBhZGRlZCBjb3N0IG9mIG5vdCBiZWluZyBhYmxlIHRvIHVzZSBleGlzdGlu ZyAibmF0aXZlIiBjb2RlY3Mgd2lsbCANCj4+IHZhcnkgYm90aCBpbiBhbW91bnQgYW5kIHdoZXJl IHRoZSBjb3N0IGhhcyB0byBiZSB0YWtlbi4gRWxpbWluYXRpbmcgDQo+PiBpdCBpcyBpbmRlZWQg YW4gb3B0aW1pemF0aW9uLCBidXQgdGhlIHRvdGFsIGNvc3Qgc2F2aW5ncyBtYXkgc3RpbGwgYmUg DQo+PiBzaWduaWZpY2FudC4NCj4+DQo+PiBXaXRoIHRoZSBjdXJyZW50IGRlc2lnbiBhbmQgdG8g bXkgdW5kZXJzdGFuZGluZywgaXQgd2lsbCBiZSB0aGUgDQo+PiBicm93c2VyIHZlbmRvcidzIGNo b2ljZSB0byBhZGQgb3B0aW9uYWwgY29kZWNzLCBpbmNsdWRpbmcgYW55ICJuYXRpdmUiDQo+PiBk b21haW4gY29kZWNzLiAgVGhlIGNob2ljZSBtYXkgcG9zc2libHkgYmUgZGVsZWdhdGVkIHRvIGlu ZGl2aWR1YWwgDQo+PiB3ZWIgZGV2ZWxvcGVycyBtYWtpbmcgdXNlIG9mIFdlYlJUQyBmdW5jdGlv bmFsaXR5LiBBIGJyb3dzZXIgdmVuZG9yIA0KPj4gd2lsbCBhcmd1YWJseSBoYXZlIHRvIGtub3cg ZWFjaCB0YXJnZXQgcGxhdGZvcm0gdG8gc29tZSBleHRlbnQsIGJ1dCANCj4+IGl0IGNhbiBoYXJk bHkgYmUgYXNzdW1lZCB0aGF0IGEgd2ViIGRldmVsb3BlciBrbm93cyB0aGUgY2FwYWJpbGl0aWVz IA0KPj4gb2YgYWxsIGRldmljZXMgdGhhdCB3aWxsIHVzZSB0aGUgV2ViUlRDLWVuYWJsZWQgc2l0 ZSB1bmxlc3MgdGhlIA0KPj4gYnJvd3NlciBjYW4gcHJvdmlkZSB0aGUgbmVlZGVkIGluZm9ybWF0 aW9uLiBUaGVyZSBpcyBhIHJpc2sgdGhhdCANCj4+ICJuYXRpdmUiIGNvZGVjcyBpbiBkZXZpY2Vz IGFyZSBub3Qgd2VsbCBoYW5kbGVkLCB1bmxlc3MgdGhlIA0KPj4gbW90aXZhdGlvbnMgYW5kIG1l dGhvZHMgdG8gbWFrZSB1c2Ugb2YgdGhlbSBhcmUgYmV0dGVyIHNwZWNpZmllZC4NCj4+DQo+PiBX aGlsZSBhbnkgYXVkaW8gY29kZWNzIGJlc2lkZXMgdGhlIE1USSBvbmVzIGFyZSBjbGVhcmx5IG9w dGlvbmFsLCBJIA0KPj4gYmVsaWV2ZSB0aGUgc3VnZ2VzdGVkIHRleHQgYWRkaXRpb24gb24gb3B0 aW9uYWwgYXVkaW8gY29kZWNzIHRvIHRoZSANCj4+IFJUQ1dFQiBhdWRpbyBkcmFmdCBpbiBUaWNr ZXQgIzEyDQo+PiAoaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcnRjd2ViL3RyYWMvdGlj a2V0LzEyIykgdG8gYmUgdG9vIA0KPj4gYnJpZWYgY29uc2lkZXJpbmcgdGhlIGFib3ZlLg0KPj4N Cj4+IEluIHRoYXQgZHJhZnQsIEkgd291bGQgcHJlZmVyIHNvbWV0aGluZyBtb3JlIGluIGxpbmUg d2l0aDoNCj4+DQo+PiAiSWYgb3RoZXIgc3VpdGFibGUgYXVkaW8gY29kZWNzIGFyZSBhdmFpbGFi bGUgdG8gdGhlIGJyb3dzZXIgdG8gdXNlLCANCj4+IGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhl eSBhcmUgYWxzbyBpbmNsdWRlZCBpbiB0aGUgb2ZmZXIgaW4gb3JkZXIgDQo+PiB0byBtYXhpbWl6 ZSB0aGUgcG9zc2liaWxpdHkgdG8gZXN0YWJsaXNoIHRoZSBzZXNzaW9uIHdpdGhvdXQgdGhlIG5l ZWQgDQo+PiBmb3IgYXVkaW8gdHJhbnNjb2RpbmciLg0KPj4NCj4+IEFzc3VtaW5nIHRoYXQgdGhl IGJyb3dzZXIgdmVuZG9yIChvciB3ZWIgZGV2ZWxvcGVyKSBpcyBzdWZmaWNpZW50bHkgDQo+PiBj b25jZXJuZWQgd2l0aCBjb2RlY3MgdG8gcmVhZCB0aGUgYXVkaW8gY29kZWNzIGRyYWZ0IChvciB0 aGUgDQo+PiBjb3JyZXNwb25kaW5nIFJGQyB0by1iZSksIHRoZSBhYm92ZSB0ZXh0IG1heSwgYXMg YSBzdGFydCwgZ2l2ZSBzb21lIA0KPj4gYWRkZWQgZ3VpZGFuY2Ugd2h5IG5vbi1NVEkgY29kZWNz IG1heSBiZSBkZXNpcmFibGUgdG8gY29uc2lkZXIgaW4gDQo+PiBhZGRpdGlvbiB0byB0aGUgTVRJ IG9uZXMuDQo+Pg0KPj4gQ2hlZXJzLA0KPj4gQm8NCj4+DQo+PiBNdWx0aW1lZGlhIFRlY2hub2xv Z2llcw0KPj4gRXJpY3Nzb24gUmVzZWFyY2gNCj4+IEbDpHLDtmdhdGFuIDYNCj4+IFNFLTE2NCA4 MCwgS2lzdGEsIFN3ZWRlbg0KPj4gd3d3LmVyaWNzc29uLmNvbQ0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QN Cj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWINCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5ydGN3ZWIgbWFpbGluZyBsaXN0 DQo+cnRjd2ViQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLgpUaGFuayB5b3UuCgo= From ralphm@ik.nu Mon Jul 22 08:06:13 2013 Return-Path: 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 D5E7E21E80B6; Mon, 22 Jul 2013 08:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 hB--a1FzGdpT; Mon, 22 Jul 2013 08:06:08 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [IPv6:2001:16f8:4::61]) by ietfa.amsl.com (Postfix) with ESMTP id 7341B11E80F2; Mon, 22 Jul 2013 08:06:08 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id D664FA1047; Mon, 22 Jul 2013 17:06:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id IcMi5T779wHw; Mon, 22 Jul 2013 17:05:43 +0200 (CEST) Received: from [192.168.3.215] (s53751670.adsl.online.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id E3E6DA1021; Mon, 22 Jul 2013 17:05:42 +0200 (CEST) Message-ID: <51ED4A45.9000703@ik.nu> Date: Mon, 22 Jul 2013 17:05:41 +0200 From: Ralph Meijer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: public-webrtc@w3.org, rtcweb@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stox@ietf.org, XMPP Jingle Subject: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:06:14 -0000 Hi all, I would like to inform the group of the recent formation [1] of the Jingle Special Interest Group (SIG) at the XMPP Standards Foundation (XSF). The recent increase of activity in the WebRTC and rtcweb working groups and related high-profile product developments and announcements were reasons for the XMPP Council to decide to concentrate efforts around Jingle in a SIG. Jingle [2] is a general framework for managing media sessions between XMPP Sessions, including, but not limited to, audio/video streams, file transfer and application sharing. There are several documents describing applications of Jingle and the used transports, most linked from the overall framework specification [3]. The specification of Jingle RTP Sessions [4], most relevant to these working groups, defines a Jingle application type for negotiating RTP sessions. It has been designed such that interoperability with SIP-based systems is possible. This includes mapping negotiation parameters to and from SDP, while remaining a signaling protocol in its own right (not merely SDP in angle brackets). The following work items were defined in the kick-off meeting last Wednesday, July 17 [5, raw log 6]: * Re-examining the state of the various Jingle proposals. * Polishing Jingle File Transfer. * Updating the SDP mapping in [4], including BUNDLE and Trickle-ICE improvements. * Documenting and communicating the value proposition of Jingle/XMPP. This SIG already includes a number of people participating in discussions on the WebRTC and rtcweb mailing lists and is lead by Dave Cridland (chair), Philipp Hancke, Lance Stout and myself. It is open to anyone, and we are looking forward to cooperate with the WebRTC and rtcweb working groups to improve both WebRTC and Jingle. The discussion venues are the Jingle mailing list [7] and the Jingle XMPP multi-user chat room [8]. Our next meeting in the MUC room is Wednesday July 24 at 15:30 UTC. This group's experience and input would be highly appreciated, and your participation in both the meeting and the on-going discussion would be most welcome. Thanks, Ralph Meijer [1] [2] [3] [4] [5] [6] [7] [8] From ibc@aliax.net Mon Jul 22 08:15:03 2013 Return-Path: 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 43C1911E811E for ; Mon, 22 Jul 2013 08:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 2LqAmdTVcXfu for ; Mon, 22 Jul 2013 08:14:58 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id C838711E8102 for ; Mon, 22 Jul 2013 08:14:57 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id n1so3654409qcw.2 for ; Mon, 22 Jul 2013 08:14:57 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=e4BtpNM+wPUGcYN+3ZLUpSJN2CvgqTOQiTSueWegWdU=; b=hoy04bcXoGb8dYcblRiiC3m3znFQA5iP8DwD8dqbTobCo3Ylb43+kCp7Bcw6Oqul01 DsRHHAHH+oT4afHmxU4F2NioXxXlBkiyIgnWNEJCSeslRE/7omC5yqyqpis1iqkJlX5V dvRZs6UIoZeKDbcWdPmWwHgZ/RA48SmQEEx/77QLHRoJQP1G7o8wUKL09KwKz+w/Y2bo ufokgdCsXv3SMSPLrRBlSqkoCm0MFJ1qWBcJTLUYFe7blIXkyVCslaMTaSOqlx96D5zz RPv+yrFZrMLZxtmLKKFR8TH6rOTesRIRSn9Yx0yc5MB774syITFHq1TkwjsNg9TJx+T1 TCOg== X-Received: by 10.49.48.19 with SMTP id h19mr33440892qen.9.1374506096969; Mon, 22 Jul 2013 08:14:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 22 Jul 2013 08:14:36 -0700 (PDT) In-Reply-To: <51ED4A45.9000703@ik.nu> References: <51ED4A45.9000703@ik.nu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 22 Jul 2013 17:14:36 +0200 Message-ID: To: Ralph Meijer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkEWBaZ3ZqP/bOM2G9gC5GLb+WBm5/detr3y45V7LDDb82IVfLerau09FCdqkq4SiI8X/ZL Cc: stox@ietf.org, XMPP Jingle , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:15:03 -0000 Great. First thing you should complain about is the fact that current WebRTC specification makes unfeasible for a browser to use SDP-XML as defined by XEP-0167. So if you have a SIP server you will be able to directly connect from the browser, but if you have a Jingle server you will need a gateway. 2013/7/22 Ralph Meijer : > Hi all, > > I would like to inform the group of the recent formation [1] of the Jingl= e > Special Interest Group (SIG) at the XMPP Standards Foundation (XSF). The > recent increase of activity in the WebRTC and rtcweb working groups and > related high-profile product developments and announcements were reasons = for > the XMPP Council to decide to concentrate efforts around Jingle in a SIG. > > Jingle [2] is a general framework for managing media sessions between XMP= P > Sessions, including, but not limited to, audio/video streams, file transf= er > and application sharing. There are several documents describing applicati= ons > of Jingle and the used transports, most linked from the overall framework > specification [3]. > > The specification of Jingle RTP Sessions [4], most relevant to these work= ing > groups, defines a Jingle application type for negotiating RTP sessions. I= t > has been designed such that interoperability with SIP-based systems is > possible. This includes mapping negotiation parameters to and from SDP, > while remaining a signaling protocol in its own right (not merely SDP in > angle brackets). > > The following work items were defined in the kick-off meeting last > Wednesday, July 17 [5, raw log 6]: > > * Re-examining the state of the various Jingle proposals. > * Polishing Jingle File Transfer. > * Updating the SDP mapping in [4], including BUNDLE and Trickle-ICE > improvements. > * Documenting and communicating the value proposition of Jingle/XMPP. > > This SIG already includes a number of people participating in discussions= on > the WebRTC and rtcweb mailing lists and is lead by Dave Cridland (chair), > Philipp Hancke, Lance Stout and myself. It is open to anyone, and we are > looking forward to cooperate with the WebRTC and rtcweb working groups to > improve both WebRTC and Jingle. > > The discussion venues are the Jingle mailing list [7] and the Jingle XMPP > multi-user chat room [8]. Our next meeting in the MUC room is Wednesday J= uly > 24 at 15:30 UTC. This group's experience and input would be highly > appreciated, and your participation in both the meeting and the on-going > discussion would be most welcome. > > Thanks, > > Ralph Meijer > > [1] > [2] > [3] > [4] > [5] > [6] > [7] > [8] > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 I=C3=B1aki Baz Castillo From miconda@gmail.com Mon Jul 22 08:28:51 2013 Return-Path: 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 CD80521E8099; Mon, 22 Jul 2013 08:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HoHQUwISgXv3; Mon, 22 Jul 2013 08:28:45 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 07A8E21E8063; Mon, 22 Jul 2013 08:28:44 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so6066654wgh.33 for ; Mon, 22 Jul 2013 08:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=o6UMUpZEhoUIpw5I1Jay1Rj9KBBc7YjlcpB6J5wEiwE=; b=ULHKBZV54+im4RzAcqD+EBHbRBnzpeXK2mMel5m3/d3akv8ijTsOj9mL1mTVEi6Ha9 26jH37VBLGoUqDdr1lK4KBOMH6zmfOBlGgN/7mV6ZKWSVD2krt0n5dBWZY3VoD8zhHoS Ih21beRSPmUvICEz9xr0lo1/fP5DshxIFpz7/VF299obwHeMP82XIzBFBdaZNNjFzKyZ ibgnPkhSqGPkqFcrAyfQVAZd0QzfC+dLDDpDSwGT9H9v2yIJltgHF1DY3FWdf1g9zLyX vH5NH2YWxwpEEBIDtg3bweOvT8TsDiMOWxPNgqTUsSrI34H5nWpBmNqHEufl8SEgr9d7 DGqA== X-Received: by 10.194.179.129 with SMTP id dg1mr20473131wjc.38.1374506917008; Mon, 22 Jul 2013 08:28:37 -0700 (PDT) Received: from [127.0.0.1] (ns.asipto.com. [213.133.111.169]) by mx.google.com with ESMTPSA id i1sm66815367wiz.6.2013.07.22.08.28.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 08:28:36 -0700 (PDT) Message-ID: <51ED4FA2.8070603@gmail.com> Date: Mon, 22 Jul 2013 17:28:34 +0200 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Ralph Meijer References: <51ED4A45.9000703@ik.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: stox@ietf.org, "public-webrtc@w3.org" , "rtcweb@ietf.org" , XMPP Jingle Subject: Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: miconda@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:28:52 -0000 On 7/22/13 5:14 PM, Iñaki Baz Castillo wrote: > Great. First thing you should complain about is the fact that current > WebRTC specification makes unfeasible for a browser to use SDP-XML as > defined by XEP-0167. So if you have a SIP server you will be able to > directly connect from the browser, but if you have a Jingle server you > will need a gateway. You are obviously misinforming here. SIP is the signaling protocol and a SIP server has really little to deal with SDP -- I'm sure you know that. And one cannot call directly a SIP endpoint from the browser, as SIP is not a mandatory signaling protocol, so there is extensive need of coding a javascript SIP stack (or reusing an existing one). Cheers, Daniel > > 2013/7/22 Ralph Meijer : >> Hi all, >> >> I would like to inform the group of the recent formation [1] of the Jingle >> Special Interest Group (SIG) at the XMPP Standards Foundation (XSF). The >> recent increase of activity in the WebRTC and rtcweb working groups and >> related high-profile product developments and announcements were reasons for >> the XMPP Council to decide to concentrate efforts around Jingle in a SIG. >> >> Jingle [2] is a general framework for managing media sessions between XMPP >> Sessions, including, but not limited to, audio/video streams, file transfer >> and application sharing. There are several documents describing applications >> of Jingle and the used transports, most linked from the overall framework >> specification [3]. >> >> The specification of Jingle RTP Sessions [4], most relevant to these working >> groups, defines a Jingle application type for negotiating RTP sessions. It >> has been designed such that interoperability with SIP-based systems is >> possible. This includes mapping negotiation parameters to and from SDP, >> while remaining a signaling protocol in its own right (not merely SDP in >> angle brackets). >> >> The following work items were defined in the kick-off meeting last >> Wednesday, July 17 [5, raw log 6]: >> >> * Re-examining the state of the various Jingle proposals. >> * Polishing Jingle File Transfer. >> * Updating the SDP mapping in [4], including BUNDLE and Trickle-ICE >> improvements. >> * Documenting and communicating the value proposition of Jingle/XMPP. >> >> This SIG already includes a number of people participating in discussions on >> the WebRTC and rtcweb mailing lists and is lead by Dave Cridland (chair), >> Philipp Hancke, Lance Stout and myself. It is open to anyone, and we are >> looking forward to cooperate with the WebRTC and rtcweb working groups to >> improve both WebRTC and Jingle. >> >> The discussion venues are the Jingle mailing list [7] and the Jingle XMPP >> multi-user chat room [8]. Our next meeting in the MUC room is Wednesday July >> 24 at 15:30 UTC. This group's experience and input would be highly >> appreciated, and your participation in both the meeting and the on-going >> discussion would be most welcome. >> >> Thanks, >> >> Ralph Meijer >> >> [1] >> [2] >> [3] >> [4] >> [5] >> [6] >> [7] >> [8] >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From ralphm@ik.nu Mon Jul 22 08:47:26 2013 Return-Path: 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 401C211E8125; Mon, 22 Jul 2013 08:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 JMKd4+rt5zzI; Mon, 22 Jul 2013 08:47:12 -0700 (PDT) Received: from mag.ik.nu (mag.ik.nu [83.98.201.61]) by ietfa.amsl.com (Postfix) with ESMTP id 09ECA11E80D9; Mon, 22 Jul 2013 08:47:11 -0700 (PDT) Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id 9A748A1030; Mon, 22 Jul 2013 17:47:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at ik.nu Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 2gEMjMyogze3; Mon, 22 Jul 2013 17:46:48 +0200 (CEST) Received: from [192.168.3.215] (s53751670.adsl.online.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id 16F6FA100F; Mon, 22 Jul 2013 17:46:48 +0200 (CEST) Message-ID: <51ED53E6.10400@ik.nu> Date: Mon, 22 Jul 2013 17:46:46 +0200 From: Ralph Meijer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <51ED4A45.9000703@ik.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: stox@ietf.org, XMPP Jingle , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: [rtcweb] XSF Jingle Special Interest Group. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:47:26 -0000 On 2013-07-22 17:14, I=C3=B1aki Baz Castillo wrote: > Great. First thing you should complain about is the fact that current > WebRTC specification makes unfeasible for a browser to use SDP-XML as > defined by XEP-0167. So if you have a SIP server you will be able to > directly connect from the browser, but if you have a Jingle server you > will need a gateway. Hi I=C3=B1aki, I have been following the recent discussions for a while now, and think=20 I understand the various stand points, including yours. As I mentioned in my announcement, mapping SDP to Jingle's negotiation=20 parameters is indeed one of the concerns we are going to look into.=20 Philipp's work on his WebRTC plugin for Strophe.js [1], which uses=20 Jingle signalling, has shown that it indeed takes quite some effort to=20 map and mangle SDP to get things going. The spreadsheet questionnaire=20 that Peter Thatcher asked people to fill in (thanks!) also has several=20 comments to that effect. During our discussions on the Jingle mailing=20 list and the meeting last week, more of such comments were made. I want to stress, again, that Jingle's negotiation parameters should not=20 be referred to as a flavor of SDP expressed in XML. This is misleading,=20 as it is not managed by MMUSIC, and actually weakens your point of not=20 wanting SDP as an API surface. I can understand that looking at the=20 current specification could give that impression, though. The Jingle=20 examples are currently interleaved by SDP examples to show the mapping,=20 and we are looking into making the distinction clearer, maybe even as a=20 document separate from this one. [1] https://github.com/ESTOS/strophe.jingle PS. Yes, I messed up the subject header of the original announcement. --=20 ralphm From ibc@aliax.net Mon Jul 22 08:55:30 2013 Return-Path: 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 6650611E8113 for ; Mon, 22 Jul 2013 08:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 JnAtvI1P0Jda for ; Mon, 22 Jul 2013 08:55:25 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id D9BBB11E80EF for ; Mon, 22 Jul 2013 08:55:21 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bq6so883215qab.18 for ; Mon, 22 Jul 2013 08:55:19 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=IcXN3skJLTWZTHMpoZhv869xvUwIdlddARQUv3Eb+/A=; b=I30WtN7XKK2ss9tDqYGFtbVL0+GJI62TSn6HnOVDCYj9Ig47Wdkb/4/632cl6VMSdd qYtpYE95WTx2jinwq2KocwhBwwdOSg6teWOKiXE+VjyauP5TO9f94oCDp062OyfSeCCE GxMWfrUe2nVUE1+W4pPdrbI3AZ0DE8djHBxcdFcdLR+Ilbou9ap8kRmZnxAhN/dkfabl JJFV2LsbDCC0qtBw7n1YmKisJ2znYrLYooLOiNIbGA7zL5UQCqM6rYkhq53wZDc3/m/e fjK5EO8ktnY6311+6p3cI8+Na3anMomCyWqepwxa/0wtuNUSMFFNeel1C6jkLt0HvVvS V1nA== X-Received: by 10.224.182.79 with SMTP id cb15mr34885234qab.48.1374508519821; Mon, 22 Jul 2013 08:55:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 22 Jul 2013 08:54:59 -0700 (PDT) In-Reply-To: <51ED53E6.10400@ik.nu> References: <51ED4A45.9000703@ik.nu> <51ED53E6.10400@ik.nu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 22 Jul 2013 17:54:59 +0200 Message-ID: To: Ralph Meijer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlOHT7Oa3EyOcMDgVK9/3MzMrbik7UaRoi4hoPB3NXKYY42rFnyeuK6m/wZnwKDUklqtl8F Cc: stox@ietf.org, XMPP Jingle , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] XSF Jingle Special Interest Group. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:55:30 -0000 2013/7/22 Ralph Meijer : > Hi I=C3=B1aki, > > I have been following the recent discussions for a while now, and think I > understand the various stand points, including yours. > > As I mentioned in my announcement, mapping SDP to Jingle's negotiation > parameters is indeed one of the concerns we are going to look into. > Philipp's work on his WebRTC plugin for Strophe.js [1], which uses Jingle > signalling, has shown that it indeed takes quite some effort to map and > mangle SDP to get things going. The spreadsheet questionnaire that Peter > Thatcher asked people to fill in (thanks!) also has several comments to t= hat > effect. During our discussions on the Jingle mailing list and the meeting > last week, more of such comments were made. > > I want to stress, again, that Jingle's negotiation parameters should not = be > referred to as a flavor of SDP expressed in XML. This is misleading, as i= t > is not managed by MMUSIC, and actually weakens your point of not wanting = SDP > as an API surface. I can understand that looking at the current > specification could give that impression, though. The Jingle examples are > currently interleaved by SDP examples to show the mapping, and we are > looking into making the distinction clearer, maybe even as a document > separate from this one. Thanks for the clarification. So Jingle's session description is not just a plain-to-XML mapping of a common SDP. Good to know. However, wouldn't you prefer to have a pure JS Object with all the media and transport information you require to build your Jingle XML-SDP instead of having to parse a plain SDP string blob? Thanks a lot. -- I=C3=B1aki Baz Castillo From fippo@goodadvice.pages.de Mon Jul 22 10:16:23 2013 Return-Path: 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 6E9B211E80EF for ; Mon, 22 Jul 2013 10:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 cZ7Da4G7yp7m for ; Mon, 22 Jul 2013 10:16:17 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCC311E8180 for ; Mon, 22 Jul 2013 10:00:20 -0700 (PDT) Received: from [192.168.2.100] (p54970320.dip0.t-ipconnect.de [84.151.3.32]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6MH0HIb013182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 19:00:18 +0200 Message-ID: <51ED651B.3000401@goodadvice.pages.de> Date: Mon, 22 Jul 2013 19:00:11 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org, public-webrtc@w3.org, XMPP Jingle References: <51ED4A45.9000703@ik.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:16:23 -0000 (removed stox) Am 22.07.2013 17:14, schrieb Iñaki Baz Castillo: > Great. First thing you should complain about is the fact that current > WebRTC specification makes unfeasible for a browser to use SDP-XML as > defined by XEP-0167. I said this before, but since you insist on repeating your argument i'll repeat mine: I have running code doing exactly that. It's hard work and there are some points where this is PITA, I have discovered numerous bugs in chrome (and the jingle spec) along the way, but it's certainly not unfeasible. So far, this mapping works using the elements already defined in XEPs 0167, 0293, 0294 and 0320 even. http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.1 has a quite concrete list of features of what functionality the mapping between SDP and the xmlish SD has to define. I'd note that I consider jingle a better way to talk about the session description because it has a very clear separation between codec negotation and transport which has led to concepts like trickle-ice. Also, it defined actions like content-add which seem to have influenced unified plan. I have yet to see the current API fail completly and have been using it in ways that were certainly not imagined, e.g. early transport warmup using PRANSWER (and I still owe feedback on that to the JSEP authors; ironically, the solution is more SDP in the API). From roman@telurix.com Mon Jul 22 10:45:51 2013 Return-Path: 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 BB8E611E8140 for ; Mon, 22 Jul 2013 10:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 mwMAKWhb6vbN for ; Mon, 22 Jul 2013 10:45:46 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4F40C11E812A for ; Mon, 22 Jul 2013 10:45:45 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so6139616wes.6 for ; Mon, 22 Jul 2013 10:45:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=zl/eTam5GKqgrKHApUYZlp+ciU0amf/EiTs2VMZ5VVk=; b=dYIMiIdHJK0Z7ONulgOFodMcE5DZv6b7BFaxRmr2hkBpSJOo8qqGZmXIz/6e77blFi BCBjIyt+dKxMqGF6OGgySLM6xGUFFblPG/Ztjtmw6Nc9U9aHgQ7PSS1ELp/KGgFEDx09 tHPJ4JgoxgmVvaDmlTGiDCNPa5iPvt2bEEfrO9a3L0eF6aPayvfRK6A+VAZjP0VGEFg8 3sHojmkySVV6xQv0HDHoowSROgZeQaKf36M9zaEaG9K2d6w4nrqhAd+wST7o7JSm4r/7 5V6Y3NglUKImvCSHdL8IIT/3obfK9x0RoQndivnXETcFXZ9mXiZYNXEUvKpsyr+6zmD1 FeeA== X-Received: by 10.180.107.71 with SMTP id ha7mr19058630wib.28.1374515145193; Mon, 22 Jul 2013 10:45:45 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [2a00:1450:400c:c00::22f]) by mx.google.com with ESMTPSA id fb2sm506266wic.4.2013.07.22.10.45.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 10:45:44 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so1375999wgh.14 for ; Mon, 22 Jul 2013 10:45:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.21.209 with SMTP id x17mr19112325wie.47.1374515143516; Mon, 22 Jul 2013 10:45:43 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Mon, 22 Jul 2013 10:45:43 -0700 (PDT) In-Reply-To: <51ED651B.3000401@goodadvice.pages.de> References: <51ED4A45.9000703@ik.nu> <51ED651B.3000401@goodadvice.pages.de> Date: Mon, 22 Jul 2013 13:45:43 -0400 Message-ID: From: Roman Shpount To: Philipp Hancke Content-Type: multipart/alternative; boundary=047d7b874000de284f04e21d3e2b X-Gm-Message-State: ALoCoQl14EB7EQglxFyCaF+RvIr6iQX1DO+krDf0jYP3Zn70/bGSmQMEkk//CNdfnHr5rYcDEZ/b Cc: XMPP Jingle , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:45:51 -0000 --047d7b874000de284f04e21d3e2b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke wrote: > I said this before, but since you insist on repeating your argument i'll > repeat mine: I have running code doing exactly that. > > It's hard work and there are some points where this is PITA, I have > discovered numerous bugs in chrome (and the jingle spec) along the way, but > it's certainly not unfeasible. > > Out of curiosity, does the same code work with Firefox? _____________ Roman Shpount --047d7b874000de284f04e21d3e2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke = <fippo@goodadvice.pages.de> wrote:
I said this before, but since you insist on repeating your argument i'l= l repeat mine: I have running code doing exactly that.

It's hard work and there are some points where this is PITA, I have dis= covered numerous bugs in chrome (and the jingle spec) along the way, but it= 's certainly not unfeasible.


Out of curiosity, does the same code work with F= irefox?
_____________
Roman Shpount

--047d7b874000de284f04e21d3e2b-- From ibc@aliax.net Mon Jul 22 10:46:49 2013 Return-Path: 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 3FF5911E8145 for ; Mon, 22 Jul 2013 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 ArRUZqgvY5Vz for ; Mon, 22 Jul 2013 10:46:44 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 434BF11E8143 for ; Mon, 22 Jul 2013 10:46:44 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id bq6so616097qab.5 for ; Mon, 22 Jul 2013 10:46:43 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=0XNQtIjOm5ckNNWjtD4hAmS/UuH2LusuXO9odwPCDus=; b=EwfifsH/CpBSfRDchgp8qwn+GlhNU9Tfq2ISVK675G+PJH3hjWFTtE/w7hVmM2rHXU gTPZ1FcqaCbZyEX6Wt+QpxcWm4eUF5oQIQUKOjv7HRRiscB1hV8zXiMf7ngV9Kol+gvg zD2ZhEpffCCWCB6kCldXHPNnfeCuM9wUkj5ByZgk4jshi0MokiXq6g0vP/bcPb1fURWa gENi5po9JE55mldvZVv/HiQlaLhB750N6Z2HI1hO39o/zjwkx2a3P61aXmyJAzFBbgCW vSp7zEXm0Y6oDZZh4LV+55Nl1R5XUuKW5MLvi/z7Ww6Gahs1prwaxVr6lOHcMFsTRTW2 s0dw== X-Received: by 10.49.84.164 with SMTP id a4mr34418627qez.4.1374515203652; Mon, 22 Jul 2013 10:46:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 22 Jul 2013 10:46:23 -0700 (PDT) In-Reply-To: <51ED651B.3000401@goodadvice.pages.de> References: <51ED4A45.9000703@ik.nu> <51ED651B.3000401@goodadvice.pages.de> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 22 Jul 2013 19:46:23 +0200 Message-ID: To: Philipp Hancke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlsM1lHZuqiOSzp7L4IY1Vcz1xG1C4paU87xTjKzypk75R90i46hPitr5TytygU0x2vAnr+ Cc: XMPP Jingle , "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:46:49 -0000 2013/7/22 Philipp Hancke : > Am 22.07.2013 17:14, schrieb I=C3=B1aki Baz Castillo: > >> Great. First thing you should complain about is the fact that current >> WebRTC specification makes unfeasible for a browser to use SDP-XML as >> defined by XEP-0167. > > > I said this before, but since you insist on repeating your argument i'll > repeat mine: I have running code doing exactly that. > > It's hard work and there are some points where this is PITA, I have > discovered numerous bugs in chrome (and the jingle spec) along the way, b= ut > it's certainly not unfeasible. > > > So far, this mapping works using the elements already defined in XEPs 016= 7, > 0293, 0294 and 0320 even. > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-4.1 has a qu= ite > concrete list of features of what functionality the mapping between SDP a= nd > the xmlish SD has to define. Thanks for the information. Just wondering if you would feel more comfortable with a WebRTC API that provides you real JS Objects/Classes with all the media parameters and transport information (instead of a SDP blob string) so you don't need to parse a plain-SDP (which will be different in each vendor's browser and browser's release and others WebRTC compatible devices) but instead take the data from JS Object structures and use it to construct your own signaling protocol. Thanks a lot. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jul 22 10:51:00 2013 Return-Path: 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 187C811E811F for ; Mon, 22 Jul 2013 10:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 1dhzFpjkn8Cb for ; Mon, 22 Jul 2013 10:50:55 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD3111E8122 for ; Mon, 22 Jul 2013 10:50:43 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id u12so3762338qcx.40 for ; Mon, 22 Jul 2013 10:50:38 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=inHUwQwgo14azRQm8mpT46lrosLTgK41FIMHZrAQ8mw=; b=FWh5h/o2EQZ08t5j9maUX/nWM25H88YOOOn8HQKVer4NU3FF7UgVrtIXLROHzOATVR WkOzeNMVZg30UB7leYqaFlODy6+d+90SE/9h8k9ZM6mL8/9HWvPwYKxUdTxTTSMtl0e7 YkeK3wNauziYq5QHPuK75Hl/KLoG2vG/9rFbRHxVLboXyxPE+EiAcpNfdn6nZlvyOUBP PqhjwDklwBvav0AnjAVHI25HTM3trywLAxwJqyIP4zG14HFDGbDbDwRgoW81/svSwy8z VHONJe6Ct+uS+0WStZ0PXuiZON6CwEZKN3hV3u0xyaW82TiBNc+fIfz5iVqSvrtiLknX +Wow== X-Received: by 10.224.182.79 with SMTP id cb15mr35545818qab.48.1374515438059; Mon, 22 Jul 2013 10:50:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 22 Jul 2013 10:50:17 -0700 (PDT) In-Reply-To: References: <51ED4A45.9000703@ik.nu> <51ED651B.3000401@goodadvice.pages.de> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 22 Jul 2013 19:50:17 +0200 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkBq923/JlRVB7qxM9WO14iJLLfxdt/sE7hkuQU+aPjcb+okPxueyU5SMZ0AwTRq3R7sUG2 Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" , XMPP Jingle Subject: Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:51:00 -0000 2013/7/22 Roman Shpount : > On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke > wrote: >> >> I said this before, but since you insist on repeating your argument i'll >> repeat mine: I have running code doing exactly that. >> >> It's hard work and there are some points where this is PITA, I have >> discovered numerous bugs in chrome (and the jingle spec) along the way, = but >> it's certainly not unfeasible. >> > > Out of curiosity, does the same code work with Firefox? And will it work with Opera, IE and any other browser without adapting the code to the SDP those browsers will produce? and will it remain working in future versions of Chrome and other browsers? If it was a real JS API and the browsers properly implement it, then the answer to all these questions would be "yes". But since this is about dealing with a SDP blob string that can be represented in many "compatible" ways by different browsers, I don't see it clear (regardless I don't doubt at all about the quality of the JS code which seems really good). Regards. -- I=C3=B1aki Baz Castillo From roman@telurix.com Mon Jul 22 11:15:25 2013 Return-Path: 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 6419811E811D for ; Mon, 22 Jul 2013 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 swUJRN8siZ5K for ; Mon, 22 Jul 2013 11:15:20 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 94A0011E811E for ; Mon, 22 Jul 2013 11:15:19 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so3058602wid.5 for ; Mon, 22 Jul 2013 11:15:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=8h1pQwZVkfGEr0Ulk1MPEsHZuTamq1EOj1UFtjLcVoI=; b=aTTU1Asvih4FRRiHSkMqe6gzKbNwRN8hm2ITcX4VNoDJ+d110zcvSO5hilhRFN2mFv Bj5sMw+2F2x4wnu1N7FlE/OZ4EpuNLJ1GcuJ3uO3w2UNl/SrzZ06TSFpq0IEZQ/++lT2 kUAjQrDNEt8tIngNY4+Pe7y2IVlqXD1kBeiAGWHy/1+X+9FMKCQ4W8pqAXWo/fEvXXOK DcaH5erfodh0WVJmNlfQKa0LiBgX85cITeabFrQMxkqZHOWFOUWIIjkSwfkb+Ji8fWfE zqrOi1PoicgJegaPWqOFDgVjMmlYWPToLs7iAolNrRMFA59A5SeKCILzt8BBXonnZwMs GU4A== X-Received: by 10.180.9.212 with SMTP id c20mr30429119wib.65.1374516918602; Mon, 22 Jul 2013 11:15:18 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [2a00:1450:400c:c03::22c]) by mx.google.com with ESMTPSA id d8sm685830wiz.0.2013.07.22.11.15.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 11:15:18 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so1351222wes.3 for ; Mon, 22 Jul 2013 11:15:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.173.71 with SMTP id bi7mr20431364wjc.2.1374516916808; Mon, 22 Jul 2013 11:15:16 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Mon, 22 Jul 2013 11:15:16 -0700 (PDT) Date: Mon, 22 Jul 2013 14:15:16 -0400 Message-ID: From: Roman Shpount To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=089e0112cf9a90755904e21da862 X-Gm-Message-State: ALoCoQkHbT4KN7FQSuVU4vkzCy5tetchng/TXM/FA0vlhEA1jER2GbcwsnUmGfQTeJ+rI1dUvYin Subject: [rtcweb] DataChannel Questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:15:25 -0000 --089e0112cf9a90755904e21da862 Content-Type: text/plain; charset=ISO-8859-1 I am sorry if I missed this somewhere in the draft, but I got two DataChannel related questions: First question: is it possible to bundle DataChannel with DTLS-SRTP? I do not see how this can be implemented since DTLS in DataChannel can negotiate any encryption protocol and I do not see a simple way to de-mux this on the wire. Just wanted to confirm that bundling is not something that is planned to be supported. Second question: is there a way to time synchronize DataChannel messages and real time media? For instance I want to use DataChannel for a subtitle track, is there a way to synchronize messages with video track? _____________ Roman Shpount --089e0112cf9a90755904e21da862 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am sorry if I missed this somewhere in the draft, but I got two DataChann= el related questions:

First question: is it possible to bundle DataC= hannel with DTLS-SRTP? I do not see how this can be implemented since DTLS = in DataChannel can negotiate any encryption protocol and I do not see a sim= ple way to de-mux this on the wire. Just wanted to confirm that bundling is= not something that is planned to be supported.

Second question: is there a way to time synchronize DataChannel message= s and real time media? For instance I want to use DataChannel for a subtitl= e track, is there a way to synchronize messages with video track?=A0
_____________
Roman Shpount
--089e0112cf9a90755904e21da862-- From ekr@rtfm.com Mon Jul 22 11:21:01 2013 Return-Path: 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 1CD1611E80E7 for ; Mon, 22 Jul 2013 11:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 pjoVKlq5GQKV for ; Mon, 22 Jul 2013 11:20:55 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 25BB021F8546 for ; Mon, 22 Jul 2013 11:20:55 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id a11so3884792qen.24 for ; Mon, 22 Jul 2013 11:20:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=43yM/iZEolx00l4lxCZqsJwSED1EJJv2mtalB5FhJpQ=; b=SeiEK8UE/gP8/WiNaemye7hTxoPz2Qbz8vMQ2hGF3gSco6RSB5gEg+5wg5FL5HDYqR cEV9oxCDfNZoiv2xOW1+8DRAObtf41mPAnygz1S1R+71IoVgKSp621saoeK8Mp5QMSJ1 Yxogq5806ctM9hGU3ZF+uPDsriQFQwu2qLGaoHz2LtQWm8Cqq/JNsTqidrViefW1xQ6P K80DZFrUswsbPOL+eXVC7NI2Ccv7ch2NvFG82Lb9BiqbvWGX8tbFWwqJasVPPEjJx49G sf1RRh0Q1tjWr5Xu6EOkLKE+cUT6cew+FkyRahEkfFjhVR9n585owTvLM6lCzC3ts2kG tbxw== X-Received: by 10.224.22.195 with SMTP id o3mr8480712qab.90.1374517254531; Mon, 22 Jul 2013 11:20:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Mon, 22 Jul 2013 11:20:14 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Mon, 22 Jul 2013 11:20:14 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=047d7b5da5bbb1d88504e21dbc51 X-Gm-Message-State: ALoCoQkIRIUEEVluTtDzRPqIBbQ6UMJ6PWRBBetE2Htf+vhJaOLR/1gr+cVkRvhDdo4GgHwOT7Gm Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DataChannel Questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:21:01 -0000 --047d7b5da5bbb1d88504e21dbc51 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 22, 2013 at 11:15 AM, Roman Shpount wrote: > I am sorry if I missed this somewhere in the draft, but I got two > DataChannel related questions: > > First question: is it possible to bundle DataChannel with DTLS-SRTP? I do > not see how this can be implemented since DTLS in DataChannel can negotiate > any encryption protocol and I do not see a simple way to de-mux this on the > wire. I don't understand that "negotiate any encryption protocol" means. The SCTP in the DataChannel is encrypted under DTLS. The only potential problem here could be demuxing the SCTP from non-SCTP traffic once you have demuxed DTLS versus SRTP, but we don't support anything that's non-SCTP here yet. > Just wanted to confirm that bundling is not something that is planned to > be supported. > As far as I know, it's fine. Second question: is there a way to time synchronize DataChannel messages > and real time media? For instance I want to use DataChannel for a subtitle > track, is there a way to synchronize messages with video track? You would presumably need to add the timing data into the DC messages themselves, since SCTP does not provide any real-time function. -Ekr --047d7b5da5bbb1d88504e21dbc51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 22, 2013 at 11:15 AM, Roman Shpount <roman@t= elurix.com> wrote:
I am sorry if I missed this somewhere in the= draft, but I got two DataChannel related questions:

First question:= is it possible to bundle DataChannel with DTLS-SRTP? I do not see how this= can be implemented since DTLS in DataChannel can negotiate any encryption = protocol and I do not see a simple way to de-mux this on the wire.

I don't understand that "negotiate any encrypt= ion protocol" means. The SCTP in the
DataChannel is encrypte= d under DTLS. The only potential problem here could be
demuxing t= he SCTP from non-SCTP traffic once you have demuxed DTLS versus
SRTP, but we don't support anything that's non-SCTP here yet.<= /div>

=A0
Just wa= nted to confirm that bundling is not something that is planned to be suppor= ted.

As far as I know, it's fine.


Second question: i= s there a way to time synchronize DataChannel messages and real time media?= For instance I want to use DataChannel for a subtitle track, is there a wa= y to synchronize messages with video track? =A0

You would presumably need to add the timing data into t= he DC messages
themselves, since SCTP does not provide any real-t= ime function.

-Ekr

--047d7b5da5bbb1d88504e21dbc51-- From fippo@goodadvice.pages.de Mon Jul 22 11:27:53 2013 Return-Path: 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 4E21C21F9477 for ; Mon, 22 Jul 2013 11:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.082 X-Spam-Level: X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=1.517, 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 W7EcMIlgEHYn for ; Mon, 22 Jul 2013 11:27:48 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 7427A21F93F3 for ; Mon, 22 Jul 2013 11:27:43 -0700 (PDT) Received: from [192.168.2.100] (p54970320.dip0.t-ipconnect.de [84.151.3.32]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6MIRdcK015026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 20:27:40 +0200 Message-ID: <51ED7995.3000407@goodadvice.pages.de> Date: Mon, 22 Jul 2013 20:27:33 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roman Shpount References: <51ED4A45.9000703@ik.nu> <51ED651B.3000401@goodadvice.pages.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Jingle , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:27:53 -0000 Am 22.07.2013 19:45, schrieb Roman Shpount: >> It's hard work and there are some points where this is PITA, I have >> discovered numerous bugs in chrome (and the jingle spec) along the way, but >> it's certainly not unfeasible. >> >> > Out of curiosity, does the same code work with Firefox? Yes, feel free to fork it at https://github.com/ESTOS/strophe.jingle and try the example. The core mapping has been relatively stable since I showed the first public version at the xmpp summit in Brussels six months ago. Things like chrome suddenly (in canary) requiring a mapping of a=rtcp-fb weren't helpful and required extra work, but I do not expect this to happen too often once the SDP requirements are agreed upon. It even sends to and receives rtp from Jitsi, even though no side is playing out anything yet; that can hopefully be resolved in Berlin. From roman@telurix.com Mon Jul 22 11:33:08 2013 Return-Path: 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 6103D11E80DE for ; Mon, 22 Jul 2013 11:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 27T98icE-5Sx for ; Mon, 22 Jul 2013 11:33:03 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0C311E80D5 for ; Mon, 22 Jul 2013 11:33:02 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so2238098wib.12 for ; Mon, 22 Jul 2013 11:33:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=T0o2ggbqFlDptiU3CohRhX4SVwKgurnENo82u7LOezM=; b=b7e97d3KjZ56im5M2Zc++IuSbP/Dx7Pwj2Dr3EeYvtQYjgnUljAW/fymuKRcdyNEet ptUIbmD2wszlQYg6IcIdBBSdrd/qYewji4TN21II9nwZl5lZWHFIE6Q6dEVk4iPAMKSp LedrhtEPk2LjA8XSVTq5omcGT8vemd7dSLCRpBRWlTO/Ql4Yu9YBwQEH8Tag+mng9l0n 5MEuMQkt37KJZYkUNxk7es9LvUe1ZP4PEsKyNWd07crxfMnz4KjYWUvr7QTc3ZhwH1cd MbjVO1SIhgcmXuRpIvLs4gun2/I70YhaCSDf5If+80mkQO7fzUEsexKzWe5c7MNYfxHD wLOQ== X-Received: by 10.180.185.74 with SMTP id fa10mr19444904wic.26.1374517980796; Mon, 22 Jul 2013 11:33:00 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [2a00:1450:400c:c05::232]) by mx.google.com with ESMTPSA id h8sm769778wie.1.2013.07.22.11.32.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 11:33:00 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so2246361wiv.17 for ; Mon, 22 Jul 2013 11:32:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.119.228 with SMTP id kx4mr20163438wjb.33.1374517979234; Mon, 22 Jul 2013 11:32:59 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Mon, 22 Jul 2013 11:32:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Jul 2013 14:32:59 -0400 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e012292e2e3c93e04e21de706 X-Gm-Message-State: ALoCoQlddRrQsdRLiCOtJtVicTjp9oCLaDlh/r0g/4FT56jFykkFNDH3HwYscojXp7CROI3CqWtF Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] DataChannel Questions X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:33:08 -0000 --089e012292e2e3c93e04e21de706 Content-Type: text/plain; charset=ISO-8859-1 Thank you for you response. It is all clear now. _____________ Roman Shpount --089e012292e2e3c93e04e21de706 Content-Type: text/html; charset=ISO-8859-1
Thank you for you response. It is all clear now.
_____________
Roman Shpount

--089e012292e2e3c93e04e21de706-- From thp@westhawk.co.uk Mon Jul 22 11:19:54 2013 Return-Path: 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 33B2E21F8546 for ; Mon, 22 Jul 2013 11:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=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 DGz+X3J3cUPx for ; Mon, 22 Jul 2013 11:19:47 -0700 (PDT) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by ietfa.amsl.com (Postfix) with ESMTP id 44FA311E80E7 for ; Mon, 22 Jul 2013 11:19:46 -0700 (PDT) Received: (qmail 22676 invoked from network); 22 Jul 2013 18:19:44 -0000 X-AV-Scan: clean Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp003.apm-internet.net with SMTP; 22 Jul 2013 18:19:44 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 1B80E18A034C; Mon, 22 Jul 2013 19:19:44 +0100 (BST) Received: from [192.168.157.113] (unknown [192.67.4.41]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id D595818A0341; Mon, 22 Jul 2013 19:19:43 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E782506D-DDF6-4D87-A1F3-BA61D19A6CA5" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: tim panton In-Reply-To: Date: Mon, 22 Jul 2013 19:19:50 +0100 Message-Id: <981F1A4D-245A-4F50-9A9C-6F22F00D8AC1@westhawk.co.uk> References: <51ED4A45.9000703@ik.nu> <51ED651B.3000401@goodadvice.pages.de> To: Roman Shpount X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Mon, 22 Jul 2013 11:33:13 -0700 Cc: XMPP Jingle , rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:19:54 -0000 --Apple-Mail=_E782506D-DDF6-4D87-A1F3-BA61D19A6CA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 22 Jul 2013, at 18:45, Roman Shpount wrote: > On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke = wrote: > I said this before, but since you insist on repeating your argument = i'll repeat mine: I have running code doing exactly that. >=20 > It's hard work and there are some points where this is PITA, I have = discovered numerous bugs in chrome (and the jingle spec) along the way, = but it's certainly not unfeasible. >=20 >=20 > Out of curiosity, does the same code work with Firefox? As far as Phono is concerned - yes - but we had to do some work to make = that happen, more=20 work in fact than adding DTLS on the server side, which is (frankly) = absurd. T. --Apple-Mail=_E782506D-DDF6-4D87-A1F3-BA61D19A6CA5 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 22 Jul 2013, at 18:45, Roman Shpount <roman@telurix.com> wrote:

On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke <fippo@goodadvice.pages.de> wrote:
I said this before, but since you insist on repeating your argument i'll repeat mine: I have running code doing exactly that.

It's hard work and there are some points where this is PITA, I have discovered numerous bugs in chrome (and the jingle spec) along the way, but it's certainly not unfeasible.


Out of curiosity, does the same code work with Firefox?

As far as Phono is concerned - yes - but we had to do some work to make that happen, more 
work in fact than adding DTLS on the server side, which is (frankly) absurd.

T.


--Apple-Mail=_E782506D-DDF6-4D87-A1F3-BA61D19A6CA5-- From rishi@turtleyogi.com Mon Jul 22 12:58:30 2013 Return-Path: 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 5961811E8112 for ; Mon, 22 Jul 2013 12:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 TckhxB5pmptk for ; Mon, 22 Jul 2013 12:58:25 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 809A021F8F07 for ; Mon, 22 Jul 2013 12:58:25 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so16570450iec.27 for ; Mon, 22 Jul 2013 12:58:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZmOtcMPZWDwrlZJpH2rN4UjFypPvFRddNs0HgF3XTDI=; b=AhUl2Leew4jcfug4zUnKTxiMYC05ZLc6G/swRCNCIqCtrqe3UzYrQ71okpiEwZNRDS ERMajAWtELJoDKUbuPYxBBqUHKNvsmoIRVr4nq1FJ8kEVz8kuQh1KasYZ4nN7d/YwHFw 4sn7PN0W283s5u4XvAnq6YdOnGszBlMp11+s5ol2J9/RJaa95EGJlEzQlK8HAkyteBCi BroprYQC3VN2Dn4VDffZykSQ+WKiICX/54ot4pO4mdH0DHkHNA3Cfi6aJVPhOS2Xi86+ WyEdy3W1hxm+ERefkqSxhNFjQUw2hHK36nKr1bPxYj/wZkN5KpTagXEGQoRt83RVV+Y6 M4Lw== MIME-Version: 1.0 X-Received: by 10.50.50.244 with SMTP id f20mr11064648igo.21.1374523104963; Mon, 22 Jul 2013 12:58:24 -0700 (PDT) Received: by 10.64.240.72 with HTTP; Mon, 22 Jul 2013 12:58:24 -0700 (PDT) X-Originating-IP: [122.166.88.77] In-Reply-To: <981F1A4D-245A-4F50-9A9C-6F22F00D8AC1@westhawk.co.uk> References: <51ED4A45.9000703@ik.nu> <51ED651B.3000401@goodadvice.pages.de> <981F1A4D-245A-4F50-9A9C-6F22F00D8AC1@westhawk.co.uk> Date: Tue, 23 Jul 2013 01:28:24 +0530 Message-ID: From: Hrishikesh Kulkarni To: tim panton Content-Type: multipart/alternative; boundary=047d7bd6be1268331d04e21f19e7 X-Gm-Message-State: ALoCoQkWPeOhyag6IJTKhL4yj5TrzFDE9WggMYLAOZb6BsQ604u1T/eqzu8hWZlMZB5jO5iTla2E Cc: public-webrtc@w3.org, "rtcweb@ietf.org" , XMPP Jingle Subject: Re: [rtcweb] Proposed message to send to the IETF rtcweb and W3C WebRTC working groups. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 19:58:30 -0000 --047d7bd6be1268331d04e21f19e7 Content-Type: text/plain; charset=ISO-8859-1 Yes. It took some effort on our server side for us to support Firefox with DTLS (still incomplete) as compared to Chrome with vanilla signaling. I believe we have long way to build interop in browsers: RTP, JS API and maybe Signaling (with webserver). ScreenSharing policy is yet to be resolved. I see this discussion is stuck at JS API vs JS SDP API, while equally important standards like screensharing policy are in queue. regards, Rishi On Mon, Jul 22, 2013 at 11:49 PM, tim panton wrote: > > On 22 Jul 2013, at 18:45, Roman Shpount wrote: > > On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke > wrote: > >> I said this before, but since you insist on repeating your argument i'll >> repeat mine: I have running code doing exactly that. >> >> It's hard work and there are some points where this is PITA, I have >> discovered numerous bugs in chrome (and the jingle spec) along the way, but >> it's certainly not unfeasible. >> >> > Out of curiosity, does the same code work with Firefox? > > > As far as Phono is concerned - yes - but we had to do some work to make > that happen, more > work in fact than adding DTLS on the server side, which is (frankly) > absurd. > > T. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bd6be1268331d04e21f19e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes. It took some effort on our server side for us to supp= ort Firefox with DTLS (still incomplete) as compared to Chrome with vanilla= signaling. I believe we have long way to build interop in browsers: RTP, J= S API and maybe Signaling (with webserver). ScreenSharing policy is yet to = be resolved.=A0

I see this discussion is stuck at JS API vs JS SDP API, whil= e equally important standards like screensharing policy are in queue.

regards,
Rishi


On Mon, Jul 22, 2013 at 11:49 PM, tim panton= <thp@westhawk.co.uk> wrote:

On= 22 Jul 2013, at 18:45, Roman Shpount <roman@telurix.com> wrote:

On Mon, Jul 22, 2013 at 1:00 PM, Philipp Hancke = <fippo@goodadvice.pages.de> wrote:
I said this before, but since you insist on repeating your argument i'l= l repeat mine: I have running code doing exactly that.

It's hard work and there are some points where this is PITA, I have dis= covered numerous bugs in chrome (and the jingle spec) along the way, but it= 's certainly not unfeasible.


Out of curiosity, does the same code work with F= irefox?

As far as Phono is = concerned - yes - but we had to do some work to make that happen, more=A0
work in fact than adding DTLS on the server side, which is (frankly) a= bsurd.

<= div>T.



___= ____________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--047d7bd6be1268331d04e21f19e7-- From adam@nostrum.com Mon Jul 22 13:16:37 2013 Return-Path: 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 5E66611E813F; Mon, 22 Jul 2013 13:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 0xIj3z6JHUKN; Mon, 22 Jul 2013 13:16:36 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 699C911E8145; Mon, 22 Jul 2013 13:16:36 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6MKGTvC065788 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 15:16:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51ED9318.6000003@nostrum.com> Date: Mon, 22 Jul 2013 15:16:24 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rajmohan Banavi References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070307020801070707040107" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: behave , "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:16:37 -0000 This is a multi-part message in MIME format. --------------070307020801070707040107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/18/13 07:28, Rajmohan Banavi wrote: > Hi Justin, comments inline with additional comments at the end. > > Correct, but that is a significant advantage, especially when the > web and TURN servers are separate entities. > > > IMHO, the standard spec should not be based on any specific > implementation method. Now I agree that the TURN server validation > becomes easier using this method because it does not have to do some > sort of lookup. However, some another TURN server implementer can > achieve the same functionality by providing REST API but using > randomly generated pasword (rather than use HMAC) and using some sort > of lookup for TURN username when TURN ALLOCATE request is received. I think the value here -- the value in defining a common scheme for password generation -- is that I could get an off-the-shelf TURN server from arbitrary vendor A, and run an off-the-shelf credential server from abitrary vendor B, and it would all work together. What you propose requires collusion between the TURN server provider and the credential server provider, using a not-yet-defined (and, if I read your proposal, never-publicly-defined) protocol to share credential information via a back-channel. What Justin proposes gets us this inter-vendor interop cheaply and easily. What you're counterproposing forces people into a single-vendor (or, at least, partnered) solution, which kinda defeats the purpose of defining this in an SDO in the first place. /a --------------070307020801070707040107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/18/13 07:28, Rajmohan Banavi wrote:
Hi  Justin, comments inline with additional comments at the end.

Correct, but that is a significant advantage, especially when the web and TURN servers are separate entities. 

IMHO, the standard spec should not be based on any specific implementation method. Now I agree that the TURN server validation becomes easier using this method because it does not have to do some sort of lookup. However, some another TURN server implementer can achieve the same functionality by providing REST API but using randomly generated pasword (rather than use HMAC) and using some sort of lookup for TURN username when TURN ALLOCATE request is received.

I think the value here -- the value in defining a common scheme for password generation -- is that I could get an off-the-shelf TURN server from arbitrary vendor A, and run an off-the-shelf credential server from abitrary vendor B, and it would all work together. What you propose requires collusion between the TURN server provider and the credential server provider, using a not-yet-defined (and, if I read your proposal, never-publicly-defined) protocol to share credential information via a back-channel.

What Justin proposes gets us this inter-vendor interop cheaply and easily. What you're counterproposing forces people into a single-vendor (or, at least, partnered) solution, which kinda defeats the purpose of defining this in an SDO in the first place.

/a
--------------070307020801070707040107-- From fippo@goodadvice.pages.de Mon Jul 22 13:47:08 2013 Return-Path: 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 9744F11E814E; Mon, 22 Jul 2013 13:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=1.011, 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 Uv1B3cAJhYYJ; Mon, 22 Jul 2013 13:47:02 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBC821F9C12; Mon, 22 Jul 2013 13:47:01 -0700 (PDT) Received: from [192.168.2.100] (p54970320.dip0.t-ipconnect.de [84.151.3.32]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6MKkvug017375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 22:47:00 +0200 Message-ID: <51ED9A3C.4060307@goodadvice.pages.de> Date: Mon, 22 Jul 2013 22:46:52 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Roach References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> In-Reply-To: <51ED9318.6000003@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" , mom040267@gmail.com, behave Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:47:08 -0000 Am 22.07.2013 22:16, schrieb Adam Roach: > What Justin proposes gets us this inter-vendor interop cheaply and > easily. What you're counterproposing forces people into a single-vendor > (or, at least, partnered) solution, which kinda defeats the purpose of > defining this in an SDO in the first place. Right. What Justin proposed was originally located at https://code.google.com/p/webrtc/issues/detail?id=1197 I liked the plan, implemented it in restund and improved it a litle. It was discussed at https://groups.google.com/forum/#!topic/discuss-webrtc/nn8b6UboqRA/discussion and also implemented in rfc-5766-turn-server. Rough consensus and running code... From fineberg@vline.me Tue Jul 23 08:54:06 2013 Return-Path: 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 1BA9511E829F for ; Tue, 23 Jul 2013 08:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 XtZBgIC40pHd for ; Tue, 23 Jul 2013 08:54:01 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id E872E11E82A1 for ; Tue, 23 Jul 2013 08:53:57 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id v19so10592663obq.35 for ; Tue, 23 Jul 2013 08:53:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=53DL/pek2wjS9D9twCG6bXHCH+MA9iHMMldP9bTnib8=; b=Z1HIa550cFUiKshD5Xp+7U43aQY3FH0mDtwMvm/NAcJQKH+dCnB76GxhGadhgrf3En hMzfZ6g8N04bKTKx32OcLaBrcDsy4Qm4TnKuPVnWSGDH5Qpv3EYc3y0t8A78DIszIb/H 4Qad/TcOysHdHXvPWlAv15Nza1WsY6AzAa5D7icILDlVx5jHRcQ/1Ot73YgvdyigKTxW yD4/xvPqkfVHHGDSwyLkaWGsU6+UFa93nWk3fy0N97FUKmIGtrRr8ACnGXACIR2fwwVk MnZYoXZHiToeMrIlX8MonQEdaxzrAoIHkDqnv/+XeCkIABvDsvsMQxR+lAHsE1ac3gC8 Brgw== X-Received: by 10.42.76.5 with SMTP id c5mr19070653ick.91.1374594828199; Tue, 23 Jul 2013 08:53:48 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id fu2sm3985149igb.3.2013.07.23.08.53.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 08:53:47 -0700 (PDT) Message-ID: <51EEA709.2020009@vline.me> Date: Tue, 23 Jul 2013 08:53:45 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030303020303070209040705" X-Gm-Message-State: ALoCoQnh8lNyjsb6Lk5LV/exhkH921dkv2xPxwRpx8ZeLCx2kL/BGU1jZCJogD+7KP7Ln6pgioEx Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:54:06 -0000 This is a multi-part message in MIME format. --------------030303020303070209040705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I've been thinking about this and given the ease at which RFC5285 allows for the specification of a header extension and the complexity introduced by trying to generalize the header extension to support all forms of scalability for all codecs that the generalization might not be the best approach. I'm not sure what we really gain by trying to capture all this in a single header extension rather than one per that can succinctly explain the fields without the complexity of multiplexing the bits. Thoughts? Regards, Adam On 7/19/13 3:44 PM, Stephan Wenger wrote: > Hi, > > From: Adam Fineberg > > Date: Friday, 19 July, 2013 15:12 > To: Stephan Wenger > > Cc: Justin Uberti >, > Bernard Aboba >, "avtext@ietf.org > " >, > "rtcweb@ietf.org " > > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Stephan, > > Thanks for the info and the reference. I'm not sure I follow as I'm > not at all familiar with H.265. I'll review the reference and see > what I can figure. > > StW: Good luck :-) > > It seems though to me that you are suggesting that except in the > simple case, that the data for H.265 would not be well suited to a > header extension, am I understanding you correctly? There is no > reason the middlebox couldn't get out of band signaling of the VPS as > you mention but that would not be within the scope of this header > extension. > > StW: well, if you would copy the layer_id into your header extension > (just as you need to do for the simple case), a really smart middle > box could use this information just as a decoder uses > it, assuming that it intercepted the VPS in the first place. Insofar, > I wouldn't rule out the second option on technical grounds. Whether > any of the actual products would bother to do that, ever, is another > question. I think the case ought to be documented, though. I can > help drafting text. > While we are at it: doing this right could mean that you need multiple > specs. First, a generic header extension mechanism dedicated to side > information required for pruning of RTP packet streams—ideally not > only for scalable video, although that is the main customer today. > And second, for each "payload" (at present we are talking about > H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D > extensions, which are not yet finalized), VP8, and VP9 (I know little > about the latter), plus Daala, and whatnot) a mapping of the bits > available in the generic header extension to the bits in the payload > itself (NAL header and VPS in case of H.265, NALU header in SVC, and > the fields you mention for VP8). > > Stephan > > > Any insights are appreciated. > > Regards, > Adam > > On 7/19/13 8:33 AM, Stephan Wenger wrote: >> Hi, >> I also believe that 16 bits should be enough. For H.264 and VP8 that >> has already been demonstrated. For H.265, some initial thoughts >> below. Apologies for the word-count. >> >> The scalable version of H265 (called SHVC) is currently under >> development. The current working draft can be found here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. >> Therein, the options for defining layering structures are >> considerably more complex. To start, we have 3 bits for the temporal >> ID in the NAL unit header of the H.265 version 1 (HEVC) base >> specification (temporal scalability is already nicely supported in >> version 1). Just like in SVC. In the scalable extension, the NAL >> unit header contains a six bit field that points into a data >> structure known as "Video Parameter Set" (VPS). Inside the VPS, >> those six bits are mapped to to a position in a directed graph >> (specified through "dimension_id[][]"), which tells you about the >> reference relationship of the layer in question and its parent layer. >> One can recursively follow the graph to determine what used to be >> called dependency_id, quality_id, view_id, and whatnot. The six bit >> pointer field can (or: is to be when possible) organized by the >> encoder such that it is prudent for a middle box to throw away NAL >> units (belonging to layers) with higher values of the six bit field >> first, before throwing away NAL units with lower values. Relying on >> this feature, 3+6 bits == 9 bits should be fine for the header extension. >> >> That said, the ordering by the encoder is just a recommendation, and >> there may well be cases where different pruning strategies may be >> advisable. For example, a layering structure could be constructed >> that expands into two branches, one using 2D scalable tools only, the >> other including view_id for multi view coding. By looking at the six >> bit field alone, a middle box will not be able to meaningfully remove >> NAL units belonging to one of the branches completely while pruning >> the other branch. In order to meaningfully deal with that scenario, >> there would be two options: one to represent the dimension_id[][] >> (and associated control info) in the header extension, or require the >> middle box to have access to the VPS and be able to interpret its >> content. The further could take considerably more than 16 bits and >> we would be talking about a variable length data structure. The >> latter requires the middle box to have state and a mechanism to >> intercept the VPS (through signaling—as the encrypted in-band VPS >> would not be useful under the assumption that the middle box does not >> have the key to the media—which is the motivation of the draft in the >> first place). I personally don't mind at all the second mechanism, >> as I'm a big fan of out-of-band parameter set transmission and any >> middle box must be in the signaling path anyway to meaningfully >> manipulate RTP. I do not like the first option due to its variable, >> and possibly substantial, overhead. >> >> Stephan >> >> >> From: Justin Uberti > >> Date: Friday, 19 July, 2013 06:32 >> To: Bernard Aboba > > >> Cc: "avtext@ietf.org " > >, "rtcweb@ietf.org " >> > >> Subject: Re: [rtcweb] Fwd: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Agree those are the right codecs to design for. Since in each case >> there are fairly low limits on the number of supported layers (i.e. 3 >> spatial layers for SVC), I think it should be possible to pack the >> temporal, spatial, quality layer ids into 16 bits. >> >> >> On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba >> > wrote: >> >> If we can support VP8/9 as well as H.264/5 SVC >> that would be a start. It seems doable to me. >> >> On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > > wrote: >> >>> Bernard, >>> >>> Are there other codecs you are thinking should be supported? If >>> it's generalized I would think we want to be able to cover all >>> known scalable codecs. I'll look into the H264/SVC fields to see >>> how to encode them in a generalized header. >>> >>> Regards, >>> Adam >>> >>> On 7/18/13 7:40 PM, Bernard Aboba wrote: >>>> I think it may be possible to generalize this. For example, for >>>> H.264/SVC which can support temporal, spatial and quality >>>> scalability, you would need the quality_id and dependency_id in >>>> addition to the temporal_id (what you call the temporal layer >>>> index). >>>> >>>> ------------------------------------------------------------------------ >>>> Date: Thu, 18 Jul 2013 08:45:38 -0700 >>>> From: fineberg@vline.me >>>> To: bernard_aboba@hotmail.com >>>> CC: rtcweb@ietf.org ; avtext@ietf.org >>>> >>>> Subject: Re: [rtcweb] Fwd: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> >>>> Bernard, >>>> >>>> Good question. I'm not familiar enough with the parameter >>>> requirements of all other scalable codecs to be able to >>>> generalize. If you'd like to help specify them, I'd be fine >>>> revising the draft to generalize. >>>> >>>> Regards, >>>> Adam >>>> >>>> On 7/17/13 8:26 PM, Bernard Aboba wrote: >>>> >>>> Since the need is not codec specific (e.g. it arises with >>>> any codec supporting temporal, spatial and quality >>>> scalability), why >>>> a VP8-specific RTP extension? >>>> >>>> ------------------------------------------------------------------------ >>>> Date: Wed, 17 Jul 2013 17:09:46 -0700 >>>> From: fineberg@vline.me >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] Fwd: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> >>>> Hi, >>>> >>>> I'm working on WebRTC services and have found that while >>>> developing services that forward VP8 video streams if we >>>> want to take advantage of the VP8 temporal scaling we must >>>> get the temporal layer information from the RTP header >>>> which requires us to decrypt the SRTP packets. This is >>>> undesirable both because the middle-box needs to have >>>> access to the keys as well as the because of the added >>>> overhead of the decrypt/encrypt cycle. This draft proposes >>>> an RTP header extension that will allow us to use the VP8 >>>> temporal layer information included in the header extension >>>> and therefore do forwarding without SRTP decryption. >>>> Comments welcome. >>>> >>>> Regards, >>>> Adam Fineberg >>>> fineberg at vline.com >>>> >>>> -------- Original Message -------- >>>> Subject: New Version Notification for >>>> draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> Date: Tue, 09 Jul 2013 10:02:05 -0700 >>>> From: internet-drafts at ietf.org >>>> >>>> To: Adam Fineberg >>>> >>>> >>>> >>>> >>>> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> has been successfully submitted by Adam Fineberg and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-fineberg-avtext-temporal-layer-ext >>>> Revision: 00 >>>> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >>>> Creation date: 2013-07-08 >>>> Group: Individual Submission >>>> Number of pages: 6 >>>> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >>>> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >>>> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >>>> >>>> >>>> Abstract: >>>> This document defines a mechanism by which packets of Real-Time >>>> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >>>> indicate, in an RTP header extension, the temporal layer information >>>> about the frame encoded in the RTP packet. This information can be >>>> used in a middlebox performing bandwidth management of streams >>>> without requiring it to decrypt the streams. >>>> >>>> >>>> _______________________________________________ rtcweb >>>> mailing list rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>>> -- >>>> Regards, >>>> Adam >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext > > -- > Regards, > Adam -- Regards, Adam --------------030303020303070209040705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I've been thinking about this and given the ease at which RFC5285 allows for the specification of a header extension and the complexity introduced by trying to generalize the header extension to support all forms of scalability for all codecs that the generalization might not be the best approach.  I'm not sure what we really gain by trying to capture all this in a single header extension rather than one per that can succinctly explain the fields without the complexity of multiplexing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:
Hi,

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm not at all familiar with H.265.  I'll review the reference and see what I can figure. 

StW: Good luck :-)  

It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

StW: well, if you would copy the layer_id into your header extension (just as you need to do for the simple case), a really smart middle box could use this information just as a decoder uses it, assuming that it intercepted the VPS in the first place.  Insofar, I wouldn't rule out the second option on technical grounds.  Whether any of the actual products would bother to do that, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.
While we are at it: doing this right could mean that you need multiple specs.  First, a generic header extension mechanism dedicated to side information required for pruning of RTP packet streams—ideally not only for scalable video, although that is the main customer today.  And second, for each "payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the bits available in the generic header extension to the bits in the payload itself (NAL header and VPS in case of H.265, NALU header in SVC, and the fields you mention for VP8).

Stephan


Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:
Hi,
I also believe that 16 bits should be enough.  For H.264 and VP8 that has already been demonstrated.  For H.265, some initial thoughts below.  Apologies for the word-count.

The scalable version of H265 (called SHVC) is currently under development.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerably more complex.  To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS).  Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer.  One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content.  The further could take considerably more than 16 bits and we would be talking about a variable length data structure.  The latter requires the middle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the media—which is the motivation of the draft in the first place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP.  I do not like the first option due to its variable, and possibly substantial, overhead.

Stephan   


From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.


On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
If we can support VP8/9 as well as H.264/5 SVC
that would be a start. It seems doable to me.

On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:
I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:
Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 
Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg
fineberg at vline.com

-------- Original Message --------
Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: Tue, 09 Jul 2013 10:02:05 -0700
From: internet-drafts at ietf.org
To: Adam Fineberg <fineberg at vline.com> 


A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

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

-- 
Regards,
Adam


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




_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

-- 
Regards,
Adam
 

-- 
Regards,
Adam
--------------030303020303070209040705-- From roman@telurix.com Tue Jul 23 09:22:21 2013 Return-Path: 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 3EB6211E82E0 for ; Tue, 23 Jul 2013 09:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 pTYfTKia-Vtm for ; Tue, 23 Jul 2013 09:22:16 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 06CD511E82D9 for ; Tue, 23 Jul 2013 09:22:14 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n12so622165wgh.9 for ; Tue, 23 Jul 2013 09:22:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=KDXiQGsi99e89ta9X69/x5ScHrL7ElnWC+oZ8hX+VbQ=; b=OK0lbBJ039QmopbExWyI9XLmZ58/b/9odrpIA/qi2FlDNk2YS7xlxF5fQhFpKs9JhK 2+fUwGMoaKBYQK9KGYRa+J5LYACP5qzIOa2j2+L+7W/RQ9WVSvVgNEjapbRtIZ9Eavyb ZC9z/U5kEQ3fLdB3vqKTnfeqXo+Y+789OB2hUWnxxpyEA8cOBvawYsJFLxsVBu7BdxVO 9Wk1GRSu+JDIKvqj4o4UHFLvC7o4K0aHNTGv85enscz6EpwXCYicLc8Ml4PO0Hl9/Qmv xLibaoLjtpM1+ggpDHwIb4Hqn1C8ui8+rnQ360NON/0UCCwS4x0BO1653WSvSzVgckb9 zF5Q== X-Received: by 10.180.182.229 with SMTP id eh5mr22387475wic.63.1374596532636; Tue, 23 Jul 2013 09:22:12 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [2a00:1450:400c:c03::22a]) by mx.google.com with ESMTPSA id r8sm7042117wiz.5.2013.07.23.09.22.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 09:22:12 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w60so1167994wes.1 for ; Tue, 23 Jul 2013 09:22:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.85.6 with SMTP id d6mr33344187wiz.47.1374596530407; Tue, 23 Jul 2013 09:22:10 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Tue, 23 Jul 2013 09:22:10 -0700 (PDT) Date: Tue, 23 Jul 2013 12:22:10 -0400 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=f46d0442808ee7904104e2303130 X-Gm-Message-State: ALoCoQn+vTP80Zs4+ETVQf2Ow2Qk+R2kXwh1OkHI31wu7jG1FMBfqXhgWA2KwWKk7iBXsMvl8+Rp Cc: rtcweb@ietf.org, mmusic@ietf.org, tim panton Subject: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:22:21 -0000 --f46d0442808ee7904104e2303130 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Changing the title and the mailing list to the more appropriate. The situation would be a bit clearer if patent holders were to provide the licensing policy regarding this IPR release. Given that Ericsson is actively involved in this working group, I think it would be reasonable to ask them for this. Regards, _____________ Roman Shpount On Tue, Jul 23, 2013 at 11:51 AM, Adam Roach wrote: > On 7/23/13 09:20, tim panton wrote: > > On 23 Jul 2013, at 14:00, Stefan H=E5kansson LK wrote: > > > On 7/23/13 5:03 AM, Justin Uberti wrote: > > With the compromise reached in the Unified Plan document, > > Presumably http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt > > I'll draw folks attention to this IPR claim > https://datatracker.ietf.org/ipr/2141/ > > What does that mean in practice? > > > > In practice, it has very little effect. > > For those of you unfamiliar with IETF IPR policy, it is documented in RFC > 3979: > > http://www.ietf.org/rfc/rfc3979.txt > > The disclosure Tim points to is made pursuant to section 6.1.3 of that > document. During the course of developing the unified plan, the > applications that are mentioned in that disclosure were brought to my > attention. > > The reason it has little effect in practice is that the independent claim= s > would appear to cover every plan proposal to date (plan a, plan b, unifie= d > plan, and even all of the "no plan" variations). Consequently, it does no= t > benefit any one approach over the others. > > /a > --f46d0442808ee7904104e2303130 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Changing the title and the mailing list to the more appropriate.

The= situation would be a bit clearer if patent holders were to provide the lic= ensing policy regarding this IPR release.=A0Given that Ericsson is actively= involved in this working group, I think it would be reasonable to ask them= for this.

Regards,
_____________
Roman Shpount


On Tue, Jul 23, 2013 at 11:51 AM, Adam R= oach <adam@nostrum.com> wrote:
=20 =20 =20
On 7/23/13 09:20, tim panton wrote:
On 23 Jul 2013, at 14:00, Stefan H=E5kansson LK <stefan.lk.hakanss=
on@ericsson.com> wrote:


On 7/23/13 5:03 AM, Justin Uberti wrote:

With the compromise reached in the Unified Plan document,

Presumably http://www.ietf.org/id/draft-roach=
-mmusic-unified-plan-00.txt

I'll draw folks attention to this IPR claim

https:=
//datatracker.ietf.org/ipr/2141/

What does that mean in practice?

In practice, it has very little effect.

For those of you unfamiliar with IETF IPR policy, it is documented in RFC 3979:

=20 http:= //www.ietf.org/rfc/rfc3979.txt

The disclosure Tim points to is made pursuant to section 6.1.3 of that document. During the course of developing the unified plan, the applications that are mentioned in that disclosure were brought to my attention.

The reason it has little effect in practice is that the independent claims would appear to cover every plan proposal to date (plan a, plan b, unified plan, and even all of the "no plan" variation= s). Consequently, it does not benefit any one approach over the others.

/a

--f46d0442808ee7904104e2303130-- From adam@nostrum.com Tue Jul 23 09:52:00 2013 Return-Path: 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 6E8D811E82E7; Tue, 23 Jul 2013 09:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 UydYF1hC0llp; Tue, 23 Jul 2013 09:52:00 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3871711E82D9; Tue, 23 Jul 2013 09:51:41 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6NGpcLT010652 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 11:51:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51EEB495.4070404@nostrum.com> Date: Tue, 23 Jul 2013 11:51:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roman Shpount References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org, mmusic@ietf.org, tim panton Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:52:00 -0000 On 7/23/13 11:22, Roman Shpount wrote: > The situation would be a bit clearer if patent holders were to provide > the licensing policy regarding this IPR release. Given that Ericsson > is actively involved in this working group, I think it would be > reasonable to ask them for this. If process has been properly followed, the IPR holder has already been notified by the IETF executive director. See http://www.ietf.org/rfc/rfc4879.txt (section 1 paragraph 1) I doubt agitating for action on these mailing lists is likely to produce useful results. /a From bernard_aboba@hotmail.com Tue Jul 23 12:07:28 2013 Return-Path: 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 C359911E838B; Tue, 23 Jul 2013 12:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 2JH9LhxiKR63; Tue, 23 Jul 2013 12:07:24 -0700 (PDT) Received: from blu0-omc4-s8.blu0.hotmail.com (blu0-omc4-s8.blu0.hotmail.com [65.55.111.147]) by ietfa.amsl.com (Postfix) with ESMTP id D20AD11E8380; Tue, 23 Jul 2013 12:07:17 -0700 (PDT) Received: from BLU169-W20 ([65.55.111.137]) by blu0-omc4-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Jul 2013 12:07:16 -0700 X-TMN: [Y5DyEb8sefXyStR6BBh9THoqYNyO9u/j] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_788a735f-7672-45a0-80b1-0a9af35b1860_" From: Bernard Aboba To: Adam Fineberg Date: Tue, 23 Jul 2013 12:07:16 -0700 Importance: Normal In-Reply-To: <51EEA709.2020009@vline.me> References: ,<51EEA709.2020009@vline.me> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jul 2013 19:07:16.0604 (UTC) FILETIME=[D8D773C0:01CE87D7] Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 19:07:28 -0000 --_788a735f-7672-45a0-80b1-0a9af35b1860_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I do not think it is necessary to "support all forms of scalability for all= codecs". In fact=2C I would make that an explicit "non-goal". All that = was suggested is to try to create a single extension that supports a few co= mmon cases. If it is possible to handle VP8=2C VP9 and H.264/SVC in a sin= gle extension that would be sufficient. So why not limit it to that?=20 Date: Tue=2C 23 Jul 2013 08:53:45 -0700 From: fineberg@vline.me To: stewe@stewe.org CC: juberti@google.com=3B bernard_aboba@hotmail.com=3B avtext@ietf.org=3B r= tcweb@ietf.org Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt =0A= =0A= =0A= =0A= =0A= I've been thinking about this and given the ease at which RFC5285=0A= allows for the specification of a header extension and the=0A= complexity introduced by trying to generalize the header extension=0A= to support all forms of scalability for all codecs that the=0A= generalization might not be the best approach. I'm not sure what we=0A= really gain by trying to capture all this in a single header=0A= extension rather than one per that can succinctly explain the fields=0A= without the complexity of multiplexing the bits. =0A= =20 =0A= Thoughts? =0A= =20 =0A= Regards=2C =0A= Adam =0A= =20 =0A= On 7/19/13 3:44 PM=2C Stephan Wenger=0A= wrote: =0A= =0A= =0A= =0A= Hi=2C=0A= =0A= =20 =0A= =0A= =0A= =0A= From: Adam Fineberg=0A= =0A= Date: Friday=2C 19 July=2C=0A= 2013 15:12=20 =0A= To: Stephan Wenger =0A= Cc: Justin Uberti =2C=0A= Bernard Aboba =2C=0A= "avtext@ietf.org"=0A= =2C=0A= "rtcweb@ietf.org"=0A= =0A= Subject: Re: [avtext]=0A= [rtcweb] Fwd: New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt =0A= =0A= =20 =0A= =0A= =0A= Stephan=2C =0A= =20 =0A= Thanks for the info and the reference. I'm not sure I=0A= follow as I'm not at all familiar with H.265. I'll review=0A= the reference and see what I can figure. =0A= =0A= =0A= =0A= =20 =0A= =0A= StW: Good luck :-) =0A= =0A= =20 =0A= =0A= =0A= =0A= It seems though to me=0A= that you are suggesting that except in the simple case=2C that= =0A= the data for H.265 would not be well suited to a header=0A= extension=2C am I understanding you correctly? There is no=0A= reason the middlebox couldn't get out of band signaling of=0A= the VPS as you mention but that would not be within the=0A= scope of this header extension.=0A= =0A= =0A= =0A= =20 =0A= =0A= StW:=0A= well=2C if you would copy the layer_id into your header=0A= extension (just as you need to do for the simple case)=2C a=0A= really smart middle box could use this information just as a=0A= decoder uses it=2C assuming that it intercepted the VPS in the= =0A= first place. Insofar=2C I wouldn't rule out the second option= =0A= on technical grounds. Whether any of the actual products=0A= would bother to do that=2C ever=2C is another question. I thin= k=0A= the case ought to be documented=2C though. I can help=0A= drafting text.=0A= While=0A= we are at it: doing this right could mean that you need=0A= multiple specs. First=2C a generic header extension mechanism= =0A= dedicated to side information required for pruning of RTP=0A= packet streams=97ideally not only for scalable video=2C althoug= h=0A= that is the main customer today. And second=2C for each=0A= "payload" (at present we are talking about H.264/SVC=2C=0A= H.265v1 (HEVC)=2C H.265v2 (including scalable and 3D=0A= extensions=2C which are not yet finalized)=2C VP8=2C and VP9 (I= =0A= know little about the latter)=2C plus Daala=2C and whatnot) a= =0A= mapping of the bits available in the generic header=0A= extension to the bits in the payload itself (NAL header and=0A= VPS in case of H.265=2C NALU header in SVC=2C and the fields yo= u=0A= mention for VP8).=0A= =20 =0A= =0A= Stephan=0A= =0A= =0A= =20 =0A= =20 =0A= Any insights are appreciated. =0A= =20 =0A= Regards=2C =0A= Adam =0A= =20 =0A= On 7/19/13 8:33 AM=2C Stephan=0A= Wenger wrote: =0A= =0A= =0A= Hi=2C=0A= I also believe that 16 bits should be enough. For=0A= H.264 and VP8 that has already been demonstrated. For=0A= H.265=2C some initial thoughts below. Apologies for the=0A= word-count.=0A= =20 =0A= =0A= The scalable version of H265 (called SHVC) is=0A= currently under development. The current working draft=0A= can be found here: http://phenix.int-evry.fr/jct/doc_end_us= er/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.=0A= Therein=2C the options for defining layering structures=0A= are considerably more complex. To start=2C we have 3 bits= =0A= for the temporal ID in the NAL unit header of the H.265=0A= version 1 (HEVC) base specification (temporal=0A= scalability is already nicely supported in version 1).=0A= Just like in SVC. In the scalable extension=2C the NAL=0A= unit header contains a six bit field that points into a=0A= data structure known as "Video Parameter Set" (VPS).=0A= Inside the VPS=2C those six bits are mapped to to a=0A= position in a directed graph (specified through=0A= "dimension_id[][]")=2C which tells you about the reference= =0A= relationship of the layer in question and its parent=0A= layer. One can recursively follow the graph to=0A= determine what used to be called dependency_id=2C=0A= quality_id=2C view_id=2C and whatnot. The six bit pointer= =0A= field can (or: is to be when possible) organized by the=0A= encoder such that it is prudent for a middle box to=0A= throw away NAL units (belonging to layers) with higher=0A= values of the six bit field first=2C before throwing away= =0A= NAL units with lower values. Relying on this feature=2C=0A= 3+6 bits =3D=3D 9 bits should be fine for the header=0A= extension.=0A= =20 =0A= =0A= That said=2C the ordering by the encoder is just a=0A= recommendation=2C and there may well be cases where=0A= different pruning strategies may be advisable. For=0A= example=2C a layering structure could be constructed that= =0A= expands into two branches=2C one using 2D scalable tools=0A= only=2C the other including view_id for multi view coding.= =0A= By looking at the six bit field alone=2C a middle box=0A= will not be able to meaningfully remove NAL units=0A= belonging to one of the branches completely while=0A= pruning the other branch. In order to meaningfully deal=0A= with that scenario=2C there would be two options: one to=0A= represent the dimension_id[][] (and associated control=0A= info) in the header extension=2C or require the middle box= =0A= to have access to the VPS and be able to interpret its=0A= content. The further could take considerably more than=0A= 16 bits and we would be talking about a variable length=0A= data structure. The latter requires the middle box to=0A= have state and a mechanism to intercept the VPS (through=0A= signaling=97as the encrypted in-band VPS would not be=0A= useful under the assumption that the middle box does not=0A= have the key to the media=97which is the motivation of the= =0A= draft in the first place). I personally don't mind at=0A= all the second mechanism=2C as I'm a big fan of=0A= out-of-band parameter set transmission and any middle=0A= box must be in the signaling path anyway to meaningfully=0A= manipulate RTP. I do not like the first option due to=0A= its variable=2C and possibly substantial=2C overhead.=0A= =20 =0A= =0A= Stephan =0A= =20 =0A= =0A= =20 =0A= =0A= =0A= =0A= From: Justin=0A= Uberti =0A= Date: Friday=2C=0A= 19 July=2C 2013 06:32=20 =0A= To: Bernard=0A= Aboba =0A= Cc: "avtext@ietf.org"=0A= =2C=0A= "rtcweb@ietf.org"=0A= =0A= Subject: Re:=0A= [rtcweb] Fwd: New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt =0A= =0A= =20 =0A= =0A= =0A= =0A= Agree those are the right codecs to=0A= design for. Since in each case there are fairly=0A= low limits on the number of supported layers (i.e.=0A= 3 spatial layers for SVC)=2C I think it should be=0A= possible to pack the temporal=2C spatial=2C quality= =0A= layer ids into 16 bits.=0A= =20 =0A= =20 =0A= On Fri=2C Jul 19=2C 2013 at=0A= 1:56 AM=2C Bernard Aboba =0A= =0A= wrote: =0A= =0A= =0A= If we can support VP8/9 as well as=0A= H.264/5 SVC=0A= that would be a start. It seems=0A= doable to me.=0A= =0A= =0A= =20 =0A= On Jul 18=2C 2013=2C at 8:34 PM=2C "Ada= m=0A= Fineberg" =0A= wrote: =0A= =20 =0A= =0A= =0A= =0A= Bernard=2C =0A= =20 =0A= Are there other codecs you are=0A= thinking should be supported? =0A= If it's generalized I would=0A= think we want to be able to=0A= cover all known scalable codecs.=0A= I'll look into the H264/SVC=0A= fields to see how to encode them=0A= in a generalized header. =0A= =20 =0A= Regards=2C =0A= Adam =0A= =20 =0A= On 7/18/13 7:40 PM=2C Bernard=0A= Aboba wrote: =0A= =0A= =0A= I think it may be=0A= possible to generalize this. =0A= For example=2C for H.264/SVC=0A= which can support temporal=2C=0A= spatial and quality=0A= scalability=2C you would need=0A= the quality_id and=0A= dependency_id in addition to=0A= the temporal_id (what you call=0A= the temporal layer index). =0A= =20 =0A= =20 =0A= =0A= =0A= Date: Thu=2C 18 Jul 2013=0A= 08:45:38 -0700 =0A= From: fineberg@vline.me =0A= To: =0A= bernard_aboba@hotmail.com =0A= CC: rtcweb@ietf.org=3B=0A= avtext@ietf.org =0A= Subject: Re: [rtcweb] Fwd:=0A= New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt =0A= =20 =0A= Bernard=2C =0A= =20 =0A= Good question. I'm not=0A= familiar enough with the=0A= parameter requirements of=0A= all other scalable codecs to=0A= be able to generalize. If=0A= you'd like to help specify=0A= them=2C I'd be fine revising=0A= the draft to generalize. =0A= =20 =0A= Regards=2C =0A= Adam =0A= =20 =0A= On 7/17/13 8:26 PM=2C=0A= Bernard Aboba wrote: =0A= =0A= =0A= Since the=0A= need is not codec=0A= specific (e.g. it arises=0A= with any codec=0A= supporting temporal=2C=0A= spatial and quality=0A= scalability)=2C why=0A= =20 =0A= a VP8-specific RTP=0A= extension?=20 =0A= =20 =0A= =0A= =0A= Date: Wed=2C 17 Jul 2013= =0A= 17:09:46 -0700 =0A= From: fineberg@vline.me =0A= To: rtcweb@ietf.org =0A= Subject: [rtcweb] Fwd:=0A= New Version=0A= Notification for=0A= draft-fineberg-avtext-tem= poral-layer-ext-00.txt =0A= =20 =0A= Hi=2C=0A= =0A= I'm=0A= working on WebRTC=0A= services and have=0A= found that while=0A= developing services=0A= that forward VP8=0A= video streams if we=0A= want to take=0A= advantage of the VP8=0A= temporal scaling we=0A= must get the=0A= temporal layer=0A= information from the=0A= RTP header which=0A= requires us to=0A= decrypt the SRTP=0A= packets. This is=0A= undesirable both=0A= because the=0A= middle-box needs to=0A= have access to the=0A= keys as well as the=0A= because of the added=0A= overhead of the=0A= decrypt/encrypt=0A= cycle. This draft=0A= proposes an RTP=0A= header extension=0A= that will allow us=0A= to use the VP8=0A= temporal layer=0A= information included=0A= in the header=0A= extension and=0A= therefore do=0A= forwarding without=0A= SRTP decryption.=0A= Comments welcome.=0A= =0A= Regards=2C=0A= Adam=0A= Fineberg=0A= fineberg=0A= at vline.com =0A= =20 =0A= -------- Original=0A= Message --------=0A= =0A= =0A= =0A= Subject:=0A= New=0A= Version=0A= Notification=0A= for=0A= draft-fineberg-av= text-temporal-layer-ext-00.txt=0A= =0A= =0A= Date:=0A= Tue=2C 09=0A= Jul 2013=0A= 10:02:05 -0700=0A= =0A= =0A= From:=0A= internet-drafts= =0A= at ietf.org=0A= =0A= =0A= To:=0A= Adam=0A= Fineberg =0A= =0A= =0A= =0A= =20 =0A= =20 =0A= A new version of I-D=2C= draft-fineberg-avtext-temporal-layer-ext-00.txt=0A= has been successfully submitted by Adam Fineberg and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-fineberg-avtext-temporal-layer-ext=0A= Revision: 00=0A= Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp= oral Layer Information=0A= Creation date: 2013-07-08=0A= Group: Individual Submission=0A= Number of pages: 6=0A= URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt=0A= Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext=0A= Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00=0A= =0A= =0A= Abstract:=0A= This document defines a mechanism by which packets of Real-Time=0A= Tranport Protocol (RTP) video streams encoded with the VP8 codec can=0A= indicate=2C in an RTP header extension=2C the temporal layer information= =0A= about the frame encoded in the RTP packet. This information can be=0A= used in a middlebox performing bandwidth management of streams=0A= without requiring it to decrypt the streams.=0A= =0A= =0A= =20 =0A= _________________________= ______________________=0A= rtcweb mailing list =0A= rtcweb@ietf.org=0A= =0A= https://www.ietf.org/mailman/listinfo/rtcweb=0A= =0A= =0A= =20 =0A= -- =0A= Regards=2C=0A= Adam=0A= =0A= =0A= =0A= =20 =0A= =0A= =0A= =0A= =0A= =0A= =20 =0A= _______________________________________________ =0A= rtcweb mailing list =0A= rtcweb@ietf.org =0A= https://www.ietf.org/mailman/listinfo/rtcweb =0A= =20 =0A= =0A= =0A= =20 =0A= =0A= =0A= =0A= =0A= =20 =0A= =0A= =20 =0A= _______________________________________________=0A= avtext mailing list=0A= avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext=0A= =0A= =20 =0A= -- =0A= Regards=2C=0A= Adam=0A= =0A= =0A= =0A= =0A= =20 =0A= -- =0A= Regards=2C=0A= Adam = --_788a735f-7672-45a0-80b1-0a9af35b1860_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I do not think it is necessary t= o "support all forms of scalability for all codecs". =3B =3B In fac= t=2C I would make that an explicit "non-goal". =3B All that was suggest= ed is to try to create a single extension that supports a few common cases.=  =3B =3B If it is possible to handle VP8=2C VP9 and H.264/SVC in a = single extension that would be sufficient. =3B So why not limit it to t= hat?

Date: Tue=2C 23 Jul 2013 08:53:45= -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@goo= gle.com=3B bernard_aboba@hotmail.com=3B avtext@ietf.org=3B rtcweb@ietf.org<= br>Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-f= ineberg-avtext-temporal-layer-ext-00.txt

=0A= =0A= =0A= =0A= =0A= I've been thinking about this and given the ease at which RFC5285=0A= allows for the specification of a header extension and the=0A= complexity introduced by trying to generalize the header extension=0A= to support all forms of scalability for all codecs that the=0A= generalization might not be the best approach. =3B I'm not sure wha= t we=0A= really gain by trying to capture all this in a single header=0A= extension rather than one per that can succinctly explain the fields=0A= without the complexity of multiplexing the bits.
=0A=
=0A= Thoughts?
=0A=
=0A= Regards=2C
=0A= Adam
=0A=
=0A=
On 7/19/13 3:44 PM=2C Stephan Wenger= =0A= wrote:
=0A=
=0A=
=0A= =0A=
= Hi=2C
=0A=
=0A=
=0A=
=0A= =0A=
=0A= From: Adam Fineberg=0A= <=3Bfineberg@vline.me&= gt=3B
=0A= Date: Friday=2C 19 Jul= y=2C=0A= 2013 15:12
=0A= To: Stephan Wenger <= =3Bstewe@stewe.org>=3B
=0A= Cc: Justin Uberti <= =3Bjuberti@google.com>=3B=2C=0A= Bernard Aboba <=3B= bernard_aboba@hotmail.com>=3B=2C=0A= "avtext@ietf.org"=0A= <=3Bavtext@ietf.org>= =3B=2C=0A= "rtcweb@ietf.org"=0A= <=3Brtcweb@ietf.org>= =3B
=0A= Subject: Re: [avtext]= =0A= [rtcweb] Fwd: New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt
=0A=
=0A=

=0A=
=0A=
=0A=
Stephan=2C
=0A=
=0A= Thanks for the info and the reference. =3B I'm not sure I= =0A= follow as I'm not at all familiar with H.265. =3B I'll revi= ew=0A= the reference and see what I can figure. =3B
=0A=
=0A= =0A=
=0A=
=0A=
=0A=
= StW: Good luck :-)  =3B
=0A=
=0A=
=0A=
=0A= =0A=
=0A=
It seems though to me=0A= that you are suggesting that except in the simple case=2C that= =0A= the data for H.265 would not be well suited to a header=0A= extension=2C am I understanding you correctly? =3B There is= no=0A= reason the middlebox couldn't get out of band signaling of=0A= the VPS as you mention but that would not be within the=0A= scope of this header extension.
=0A=
=0A= =0A=
=0A=
=0A=
=0A=
StW:= =0A= well=2C if you would copy the layer_id into your header=0A= extension (just as you need to do for the simple case)=2C a=0A= really smart middle box could use this information just as a=0A= decoder uses it=2C =3Bassuming =3Bthat it intercepted t= he VPS in the=0A= first place.  =3BInsofar=2C I wouldn't rule out the second = option=0A= on technical grounds.  =3BWhether any of the actual product= s=0A= would bother to do that=2C ever=2C is another question.  = =3BI think=0A= the case ought to be documented=2C though.  =3BI can help= =0A= drafting text.
=0A=
Whil= e=0A= we are at it: doing this right could mean that you need=0A= multiple specs.  =3BFirst=2C a generic header extension mec= hanism=0A= dedicated to side information required for pruning of RTP=0A= packet streams=97ideally not only for scalable video=2C althoug= h=0A= that is the main customer today.  =3BAnd second=2C for each= =0A= "payload" (at present we are talking about H.264/SVC=2C=0A= H.265v1 (HEVC)=2C H.265v2 (including scalable and 3D=0A= extensions=2C which are not yet finalized)=2C VP8=2C and VP9 (I= =0A= know little about the latter)=2C plus Daala=2C and whatnot) a= =0A= mapping of the bits available in the generic header=0A= extension to the bits in the payload itself (NAL header and=0A= VPS in case of H.265=2C NALU header in SVC=2C and the fields yo= u=0A= mention for VP8).
=0A=
=
=0A=
=0A=
= Stephan
=0A= =0A=
=0A=

=0A=
=0A= Any insights are appreciated.
=0A=
=0A= Regards=2C
=0A= Adam
=0A=
=0A=
On 7/19/13 8:33 AM=2C Stephan= =0A= Wenger wrote:
=0A=
=0A=
=0A=
Hi=2C
=0A=
I also believe that 16 bits should be enough.  =3BFo= r=0A= H.264 and VP8 that has already been demonstrated.  =3BF= or=0A= H.265=2C some initial thoughts below.  =3BApologies for= the=0A= word-count.
=0A=

=0A=
=0A=
The scalable version of H265 (called SHVC) is=0A= currently under development.  =3BThe current working dr= aft=0A= can be found here: =3Bhttp://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon= /wg11/JCTVC-M1008-v3.zip.=0A=  =3BTherein=2C the options for defining layering struct= ures=0A= are considerably more complex.  =3BTo start=2C we have = 3 bits=0A= for the temporal ID in the NAL unit header of the H.265=0A= version 1 (HEVC) base specification (temporal=0A= scalability is already nicely supported in version 1).=0A=  =3BJust like in SVC.  =3BIn the scalable extension= =2C the NAL=0A= unit header contains a six bit field that points into a=0A= data structure known as "Video Parameter Set" (VPS).=0A=  =3BInside the VPS=2C those six bits are mapped to to a= =0A= position in a directed graph (specified through=0A= "dimension_id[][]")=2C which tells you about the reference= =0A= relationship of the layer in question and its parent=0A= layer.  =3BOne can recursively follow the graph to=0A= determine what used to be called dependency_id=2C=0A= quality_id=2C view_id=2C and whatnot.  =3BThe six bit p= ointer=0A= field can (or: is to be when possible) organized by the=0A= encoder such that it is prudent for a middle box to=0A= throw away NAL units (belonging to layers) with higher=0A= values of the six bit field first=2C before throwing away= =0A= NAL units with lower values.  =3BRelying on this featur= e=2C=0A= 3+6 bits =3D=3D 9 bits should be fine for the header=0A= extension.
=0A=

=0A=
=0A=
That said=2C the ordering by the encoder is just a=0A= recommendation=2C and there may well be cases where=0A= different pruning strategies may be advisable.  =3BFor= =0A= example=2C a layering structure could be constructed that= =0A= expands into two branches=2C one using 2D scalable tools=0A= only=2C the other including view_id for multi view coding.= =0A=  =3BBy looking at the six bit field alone=2C a middle b= ox=0A= will not be able to meaningfully remove NAL units=0A= belonging to one of the branches completely while=0A= pruning the other branch.  =3BIn order to meaningfully = deal=0A= with that scenario=2C there would be two options: one to=0A= represent the dimension_id[][] (and associated control=0A= info) in the header extension=2C or require the middle box= =0A= to have access to the VPS and be able to interpret its=0A= content.  =3BThe further could take considerably more t= han=0A= 16 bits and we would be talking about a variable length=0A= data structure.  =3BThe latter requires the middle box = to=0A= have state and a mechanism to intercept the VPS (through=0A= signaling=97as the encrypted in-band VPS would not be=0A= useful under the assumption that the middle box does not=0A= have the key to the media=97which is the motivation of the= =0A= draft in the first place).  =3BI personally don't mind = at=0A= all the second mechanism=2C as I'm a big fan of=0A= out-of-band parameter set transmission and any middle=0A= box must be in the signaling path anyway to meaningfully=0A= manipulate RTP.  =3BI do not like the first option due = to=0A= its variable=2C and possibly substantial=2C overhead.
= =0A=

=0A=
=0A=
Stephan  =3B =3B
=0A=

=0A=
=0A=

=0A=
=0A= =0A= =0A=

=0A=
=0A=
=0A=
=0A=
Agree those are the right codecs to=0A= design for. Since in each case there are fairly=0A= low limits on the number of supported layers (i.e.=0A= 3 spatial layers for SVC)=2C I think it should be=0A= possible to pack the temporal=2C spatial=2C quality= =0A= layer ids into 16 bits.=0A=

=0A=
=0A=
On Fri=2C Jul 19=2C 2= 013 at=0A= 1:56 AM=2C Bernard Aboba =0A= <=3Bbernard_aboba@hotmail.com>=3B=0A= wrote:
=0A=
=0A=
=0A=
If we can support VP8/9 as well as=0A= H.264/5 SVC
=0A=
that would be a start. It seems=0A= doable to me.
=0A=
=0A=
=0A=

=0A= On Jul 18=2C 2013=2C at 8:34 PM=2C "Ada= m=0A= Fineberg" <=3Bfineberg@vline.me>=3B=0A= wrote:
=0A=
=0A=
=0A=
=0A=
=0A=
Bernard=2C
=0A=
=0A= Are there other codecs you are=0A= thinking should be supported? = =3B=0A= If it's generalized I would=0A= think we want to be able to=0A= cover all known scalable codecs.=0A= I'll look into the H264/SVC=0A= fields to see how to encode them=0A= in a generalized header.
=0A=
=0A= Regards=2C
=0A= Adam
=0A=
=0A= On 7/18/13 7:40 PM=2C Bernard=0A= Aboba wrote:
=0A=
=0A=
=0A=
I think it may be= =0A= possible to generalize this. = =3B=0A= For example=2C for H.264/SVC=0A= which can support temporal=2C=0A= spatial and quality=0A= scalability=2C you would need=0A= the quality_id and=0A= dependency_id in addition to=0A= the temporal_id (what you call=0A= the temporal layer index).  = =3B =3B=0A=
=0A=
=0A=
=0A=
=0A= Date: Thu=2C 18 Jul 2013=0A= 08:45:38 -0700
=0A= From: fineberg@vline.me
=0A= To: =0A= bernard_aboba@hotmail.com=
=0A= CC: rtcweb@ietf.org=3B=0A= avtext@ietf.org
=0A= Subject: Re: [rtcweb] Fwd:=0A= New Version Notification for=0A= draft-fineberg-avtext-temporal-layer-ext-00.txt
=0A=
=0A= Bernard=2C
=0A=
=0A= Good question. =3B I'm not= =0A= familiar enough with the=0A= parameter requirements of=0A= all other scalable codecs to=0A= be able to generalize. =3B = If=0A= you'd like to help specify=0A= them=2C I'd be fine revising=0A= the draft to generalize.
=0A=
=0A= Regards=2C
=0A= Adam
=0A=
=0A=
On 7/17/13 8:26 PM=2C=0A= Bernard Aboba wrote:
=0A=
=0A=
=0A=
Since the=0A= need is not codec=0A= specific (e.g. it arises=0A= with any codec=0A= supporting temporal=2C=0A= spatial and quality=0A= scalability)=2C why=0A=
=0A=  =3Ba VP8-specific RTP= =0A= extension?
=0A=  =3B
=0A=
=0A=
=0A= Date: Wed=2C 17 Jul 2013= =0A= 17:09:46 -0700
=0A= From: fineberg@vline.me
=0A= To: rtcweb@ietf.org
=0A= Subject: [rtcweb] Fwd:=0A= New Version=0A= Notification for=0A= draft-fineberg-avtext-tem= poral-layer-ext-00.txt
=0A=
=0A= Hi=2C
=0A=
=0A= I'm=0A= working on WebRTC=0A= services and have=0A= found that while=0A= developing services=0A= that forward VP8=0A= video streams if we=0A= want to take=0A= advantage of the VP8=0A= temporal scaling we=0A= must get the=0A= temporal layer=0A= information from the=0A= RTP header which=0A= requires us to=0A= decrypt the SRTP=0A= packets. This is=0A= undesirable both=0A= because the=0A= middle-box needs to=0A= have access to the=0A= keys as well as the=0A= because of the added=0A= overhead of the=0A= decrypt/encrypt=0A= cycle. This draft=0A= proposes an RTP=0A= header extension=0A= that will allow us=0A= to use the VP8=0A= temporal layer=0A= information included=0A= in the header=0A= extension and=0A= therefore do=0A= forwarding without=0A= SRTP decryption.=0A= Comments welcome.
=0A=
=0A= Regards=2C
=0A= Adam=0A= Fineberg
=0A=
fineberg=0A= at vline.com
= =0A=
=0A= -------- Original=0A= Message --------=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
Subject:New=0A= Version=0A= Notification=0A= for=0A= draft-fineberg-av= text-temporal-layer-ext-00.txt
Date:Tue=2C 09=0A= Jul 2013=0A= 10:02:05 -0700=0A=
From:in= ternet-drafts=0A= at ietf.org=0A=
To:Adam=0A= Fineberg&nb= sp=3B<=3Bfineberg at vline.com>=3B
=0A=
=0A=
=0A= 
A new version of I-D=2C draft-fineberg-avt=
ext-temporal-layer-ext-00.txt=0A=
has been successfully submitted by Adam Fineberg and posted to the=0A=
IETF repository.=0A=
=0A=
Filename:	 draft-fineberg-avtext-temporal-layer-ext=0A=
Revision:	 00=0A=
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp=
oral Layer Information=0A=
Creation date:	 2013-07-08=0A=
Group:		 Individual Submission=0A=
Number of pages: 6=0A=
URL:             ht=
tp://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-=
00.txt=0A=
Status:          http://datatr=
acker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext=0A=
Htmlized:        http://tools.ie=
tf.org/html/draft-fineberg-avtext-temporal-layer-ext-00=0A=
=0A=
=0A=
Abstract:=0A=
   This document defines a mechanism by which packets of Real-Time=0A=
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can=0A=
   indicate=2C in an RTP header extension=2C the temporal layer information=
=0A=
   about the frame encoded in the RTP packet.  This information can be=0A=
   used in a middlebox performing bandwidth management of streams=0A=
   without requiring it to decrypt the streams.=0A=
=0A=
=0A=
=0A= _________________________= ______________________=0A= rtcweb mailing list =0A= rtcweb@ietf.org=0A= =0A= https://www.ietf.org/mailman/listinfo/rtcweb
=0A=
=0A=
=0A=
=0A= 
-- =0A=
Regards=2C=0A=
Adam
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A= _______________________________________________
=0A= rtcweb mailing list
=0A= rtcweb@ietf.org
=0A= https://www.ietf.org/mailman/listinfo/rtcweb
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A= 
_______________________________________________=0A=
avtext mailing list=0A=
av=
text@ietf.orghttps://www.ietf.org/ma=
ilman/listinfo/avtext
=0A=
=0A=
=0A= 
-- =0A=
Regards=2C=0A=
Adam
=0A=
=0A=
=0A= =0A=
=0A=
=0A= 
-- =0A=
Regards=2C=0A=
Adam
= --_788a735f-7672-45a0-80b1-0a9af35b1860_-- From hadriel.kaplan@oracle.com Tue Jul 23 12:37:27 2013 Return-Path: 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 5315811E8379 for ; Tue, 23 Jul 2013 12:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 YReIC5HoIS2m for ; Tue, 23 Jul 2013 12:37:20 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D440F11E80D5 for ; Tue, 23 Jul 2013 12:37:19 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6NJbG5W023761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jul 2013 19:37:16 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6NJbCLJ001810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 19:37:15 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6NJbBqU015567; Tue, 23 Jul 2013 19:37:11 GMT Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jul 2013 12:37:11 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Tue, 23 Jul 2013 15:37:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30CF49@ESESSMB209.ericsson.se> <0D2B47D9-25BF-40C1-AC41-DF65093A6B94@iii.c! a> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 19:37:27 -0000 On Jul 20, 2013, at 10:26 AM, I=F1aki Baz Castillo = wrote: > 2013/7/20 Cullen Jennings : >> I will note that over half of that very small sample set is folks = that have been long termed involved in SIP and VoIP so, uh, might not be = a representative sample of type of people you are portraying it as. >=20 > It is even worse if people interested and expert in SIP tells you that > the current SDP-blob-based API is really wrong for using SIP in > WebRTC, don't you think? No, not at all - we're all jaded from past experience and we know how = bad it is already, so Cullen's right we're all tainted. Hopefully if we = ask new people, they won't know the truth and give us much more positive = results instead. Or new people might even see the SDP-based "API" and = think: "Oh cool, the API is a string blob of stuff in some archaic = inconsistent syntax format with hidden state-based dependencies and = rules... awesome! I always wanted to party like it's 1999, and here's = my chance!" -hadriel From matthew.kaufman@skype.net Tue Jul 23 13:19:31 2013 Return-Path: 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 63B5111E8130; Tue, 23 Jul 2013 13:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 b7lT+PsoaZlh; Tue, 23 Jul 2013 13:19:25 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6192D11E8112; Tue, 23 Jul 2013 13:19:22 -0700 (PDT) Received: from mail150-db9-R.bigfish.com (10.174.16.245) by DB9EHSOBE014.bigfish.com (10.174.14.77) with Microsoft SMTP Server id 14.1.225.22; Tue, 23 Jul 2013 20:19:21 +0000 Received: from mail150-db9 (localhost [127.0.0.1]) by mail150-db9-R.bigfish.com (Postfix) with ESMTP id D36ABA0170; Tue, 23 Jul 2013 20:19:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zzda00h1432Idc73hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail150-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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail150-db9 (localhost.localdomain [127.0.0.1]) by mail150-db9 (MessageSwitch) id 1374610759456070_25553; Tue, 23 Jul 2013 20:19:19 +0000 (UTC) Received: from DB9EHSMHS022.bigfish.com (unknown [10.174.16.231]) by mail150-db9.bigfish.com (Postfix) with ESMTP id 5CAA71E0046; Tue, 23 Jul 2013 20:19:19 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS022.bigfish.com (10.174.14.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 23 Jul 2013 20:19:16 +0000 Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.194]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Tue, 23 Jul 2013 20:18:39 +0000 From: "Matthew Kaufman (SKYPE)" To: Adam Roach , Roman Shpount Thread-Topic: [rtcweb] Unified plan IPR Thread-Index: AQHOh8DVjWlPWg1wtE6LFph3rvjdWJlyekSAgAA5pXA= Date: Tue, 23 Jul 2013 20:18:39 +0000 Message-ID: References: <51EEB495.4070404@nostrum.com> In-Reply-To: <51EEB495.4070404@nostrum.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" , "mmusic@ietf.org" , tim panton Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 20:19:31 -0000 Adam Roach: > > I doubt agitating for action on these mailing lists is likely to produce = useful > results. This appears to be generally true, yes. One wonders why we have them. Matthew Kaufman From juberti@google.com Tue Jul 23 13:50:30 2013 Return-Path: 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 3B16511E810C for ; Tue, 23 Jul 2013 13:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 Geh9Lq5FUsXm for ; Tue, 23 Jul 2013 13:50:30 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id DD8F311E8136 for ; Tue, 23 Jul 2013 13:50:27 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id i4so12190531oah.24 for ; Tue, 23 Jul 2013 13:50:27 -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=1WzahDGv5zenHpXjNXipRrGEVMAhrUSugYqiDAvm0lU=; b=HuNq4+SMxc5MuyfFOEthUtF01iBYtFe/1Wn9o/dgdEqtnHiddgytQxIyvP+REyQwhX l9WEZQcI5qsbr+fjFnKTYJNwyKr7sM+/s1bq4DISPP+UhnJjWfyrwJT9hwK6BbuCUa0F dwxu/Z3ThdRnubs5l4TGznZjc7Oq9dJUcA+BtusAlSt2yclFuLIFgbG1onY3IYLRfCS7 YmJg+vHKDgM5wYT9uIaX4Xe0sxoSuBlzlaO6JAN2qzXLUPrZAro4qFYWICOXv5C7TSsX MrZ1YUy8nwh4HCa6L7c0pnwRIkUDPcuJ2a8hmuN6BoqAuLdSxqcXYapVcGXbImNhkkEV KXWA== 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=1WzahDGv5zenHpXjNXipRrGEVMAhrUSugYqiDAvm0lU=; b=X7LwwNF59rUeP/4ibjGgDDg259FXnssIVBkiGvkszDf1LCJL7IUaQyaiEbq0sUwzTm acNBGe/0iACvRfMKs/Mttz7hWriJgvJXVuMUok2pd2a+FHZ15kfivSFdmJnPTG0Ggvfz LXRbB8AC+la43fMSfs0ptZsjhxp+D0DGkeyR7/5RhiqU5Pn8c8Vh22rpcNcziUUfS5Zo BegYfGZydwBKetRFn84TMo5cpa1ywMuTBQK+csNIPW914TAIO2BtwoBNhvgC2jW6ktFY X+FCM9cV0rr4pmgILQIGitX04+DZ7UoYYk2ZpPxKrD5NYjoUf3vzRuCdFY+ruQgPZ95p ta9Q== X-Received: by 10.50.134.72 with SMTP id pi8mr63574igb.7.1374612627197; Tue, 23 Jul 2013 13:50:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.132 with HTTP; Tue, 23 Jul 2013 13:45:12 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> From: Justin Uberti Date: Tue, 23 Jul 2013 16:45:12 -0400 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=047d7b2e429a59343f04e233f183 X-Gm-Message-State: ALoCoQkJjDML6IpeNsh1eSjnIssoyQrdFETifyNLgZ5AkSnShRR2BOhu49/NuPaqLAtif+Xj0ATwDCA0W3MLQmDEYnz/mRn01QHGcly0YI+ICAbTTLX82FFUPRPo1UllJXa5W8DU4Zu/vylbhShheMT/Np5T0v2Ua0THaNLKqZvhylvKY0Bw6fyLfXL6CxSwScFe7AnoX7C8 Cc: "rtcweb@ietf.org" , behave Subject: Re: [rtcweb] [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 20:50:30 -0000 --047d7b2e429a59343f04e233f183 Content-Type: text/plain; charset=UTF-8 So there are two parts to the proposal - the HTTP request for the credentials and interactions with WebRTC, and the stateless implementation that avoids the need for communication between web and TURN servers. And it is true that other implementations besides the suggested stateless one are possible, e.g. OAuth2. Would you prefer that I address the protocol and implementation parts separately in the document, and mention that other implementations with the same HTTP protocol are possible? RFC 5766 does something similar, where it defines the TURN protocol, but in Section 6.2 talks about how a "stateless stack" implementation can be used to simplify the processing on the TURN server. On Mon, Jul 22, 2013 at 5:37 PM, Oleg Moskalenko wrote: > The overall proposal by Justin: > > http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00 > > has been implemented in our rfc5766-turn-server for months, and I see > nothing proprietary in the proposal. I liked the proposal from the > beginning. Its been discussed and its been quite handy for the users - I > hear stories of success from the users. I believe that Philipp shares the > same view. > > One especially good thing about the proposal is that is does not > contradict by any means to the RFC 5766. It just specifies the way how the > passwords are stored/generated - and the RFC 5766 does not say anything > about that matter. It means that Justin's proposal is 100% compatible with > RFC 5766. > > Thanks > Oleg > http://code.google.com/p/rfc5766-turn-server/ > > > > > On Mon, Jul 22, 2013 at 1:46 PM, Philipp Hancke > wrote: > >> Am 22.07.2013 22:16, schrieb Adam Roach: >> >>> What Justin proposes gets us this inter-vendor interop cheaply and >>> easily. What you're counterproposing forces people into a single-vendor >>> (or, at least, partnered) solution, which kinda defeats the purpose of >>> defining this in an SDO in the first place. >>> >> >> Right. What Justin proposed was originally located at >> https://code.google.com/p/**webrtc/issues/detail?id=1197 >> I liked the plan, implemented it in restund and improved it a litle. It >> was discussed at https://groups.google.com/** >> forum/#!topic/discuss-webrtc/**nn8b6UboqRA/discussionand also implemented in rfc-5766-turn-server. >> >> Rough consensus and running code... >> > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > --047d7b2e429a59343f04e233f183 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So there are two parts to the proposal - the HTTP request = for the credentials and interactions with WebRTC, and the stateless impleme= ntation that avoids the need for communication between web and TURN servers= . And it is true that other implementations besides the suggested stateless= one are possible, e.g. OAuth2.

Would you prefer that I address the protocol and implem= entation parts separately in the document, and mention that other implement= ations with the same HTTP protocol are possible? RFC 5766 does something si= milar, where it defines the TURN protocol, but in Section 6.2 talks about h= ow a "stateless stack" implementation can be used to simplify the= processing on the TURN server.


On Mon,= Jul 22, 2013 at 5:37 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:
has been implemented in our rfc5766-turn-server for months, and I= see nothing proprietary in the proposal. I liked the proposal from the beg= inning. Its been discussed and its been quite handy for the users - I hear = stories of success from the users.=C2=A0 I believe that Philipp shares the = same view.

One especially good thing about the proposal is that is does= not contradict by any means to the RFC 5766. It just specifies the way how= the passwords are stored/generated - and the RFC 5766 does not say anythin= g about that matter. It means that Justin's proposal is 100% compatible= with RFC 5766.

Thanks
Oleg
http://code.google.com/p/rfc5766-tu= rn-server/




On Mon, Jul 22, 2013 at 1:46 PM, Philipp= Hancke <fippo@goodadvice.pages.de> wrote:
Am 22.07.2013 22:16, schrieb Adam Roach:
What Justin proposes gets us this inter-vendor interop cheaply and
easily. What you're counterproposing forces people into a single-vendor=
(or, at least, partnered) solution, which kinda defeats the purpose of
defining this in an SDO in the first place.

Right. What Justin proposed was originally located at
https://code.google.com/p/webrtc/issues/detail?id=3D1197=
I liked the plan, implemented it in restund and improved it a litle. It was= discussed at https://groups.google.com/forum/#!topic/discuss-webrtc/nn8b6UboqRA/discussion and als= o implemented in rfc-5766-turn-server.

Rough consensus and running code...


_______________________________________________
Behave mailing list
Behave@ietf.org
= https://www.ietf.org/mailman/listinfo/behave


--047d7b2e429a59343f04e233f183-- From cowwoc@bbs.darktech.org Tue Jul 23 14:58:32 2013 Return-Path: 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 65C6411E8289 for ; Tue, 23 Jul 2013 14:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 2i7Iuq0gePzs for ; Tue, 23 Jul 2013 14:58:27 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 77AAE11E8271 for ; Tue, 23 Jul 2013 14:58:27 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cl20so1928611qab.16 for ; Tue, 23 Jul 2013 14:58:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=xF3wxS6v2166/sIx5iwb587v/pbLiY/uih3lIF29bLc=; b=YYWm3pFasZ8JXeRKeNA5PfhWdpSpHuYQOqXL5g+xyBLn5VK3kh5vAM+dyeYFsSWl6P uo87gbhBBBVxQ4QrttBnC+lKwWXaowFGhINDyT0rlab1wBHoNMosgmrsUyNVzlo6lxPY kUZh58maqEkOVW1kMbLH8CkndnWoamNVqfxToXifSKRL0SQLZQSsvp8V12VluQ0GgiAE 0ZbN8HMAwaMqY8NMU43m5R8XQEJf0IyDExDXA4gvotDP84ptpiMtUYO2eZAAhltypPj8 b9xrDQZgv6+UVuwOPbCz4VobJiHaZdRBy4a6Nl4QliJPiauYcuwgwQhdaNIivSZ3iKZA 1SLA== X-Received: by 10.224.79.203 with SMTP id q11mr42225170qak.35.1374616706665; Tue, 23 Jul 2013 14:58:26 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id n16sm310329qae.8.2013.07.23.14.58.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 14:58:25 -0700 (PDT) Message-ID: <51EEFC6B.9090503@bbs.darktech.org> Date: Tue, 23 Jul 2013 17:58:03 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <51EEB495.4070404@nostrum.com> In-Reply-To: <51EEB495.4070404@nostrum.com> Content-Type: multipart/alternative; boundary="------------060605090502050100050201" X-Gm-Message-State: ALoCoQmZd1Wfj74X38AOPata+OwBcHExmQmt6NDAFzm39mLLbXjBiF2MgPkxGdJXYXv29M/ZAh9T Cc: "public-webrtc@w3.org" Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 21:58:32 -0000 This is a multi-part message in MIME format. --------------060605090502050100050201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 23/07/2013 12:51 PM, Adam Roach wrote: > On 7/23/13 11:22, Roman Shpount wrote: >> The situation would be a bit clearer if patent holders were to >> provide the licensing policy regarding this IPR release. Given that >> Ericsson is actively involved in this working group, I think it would >> be reasonable to ask them for this. > > If process has been properly followed, the IPR holder has already been > notified by the IETF executive director. See > http://www.ietf.org/rfc/rfc4879.txt (section 1 paragraph 1) > > I doubt agitating for action on these mailing lists is likely to > produce useful results. > > /a Hi Adam, I'm a bit concerned about the optics of what just happened. * The Working Group has been pushing for the use of SDP since 2011 (see http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html). * The first post related to the use of SDP in WebRTC came from Christer Holmberg of Ericsson on September 14th, 2011. * One of the Chairs of the Working Group and one of the Specification editors are from Ericsson. * There has been a substantial push against the use of SDP by some mailing list participants, but this was rejected by the Working Group. * Suddenly we find out that Ericsson has filed two patents related to the use of SDP in WebRTC and these were filed *after* Ericsson actively pushed for the use of SDP. Isn't there a conflict of interest here? As a Web Developer who doesn't want/need SDP to begin with, I am finding this a bitter pill to swallow. I have no problem with other people using SDP (all the power to them) but, with this IPR discovery, forcing their preference on me will have real-world consequences (no less than had we mandated the use H264 in WebRTC). 1. Do the patents imply that Web Developers will have to pay patents when deploying application on top of the Browser or Native APIs? 2. Is there a way to retrofit the API so those of us who do not want/need to use SDP are not forced to license this IPR? For example, the specification states that the initial offer/answer mechanism is out of scope. Could we do the same for SDP? Thank you, Gili --------------060605090502050100050201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 23/07/2013 12:51 PM, Adam Roach wrote:
On 7/23/13 11:22, Roman Shpount wrote:
The situation would be a bit clearer if patent holders were to provide the licensing policy regarding this IPR release. Given that Ericsson is actively involved in this working group, I think it would be reasonable to ask them for this.

If process has been properly followed, the IPR holder has already been notified by the IETF executive director. See http://www.ietf.org/rfc/rfc4879.txt (section 1 paragraph 1)

I doubt agitating for action on these mailing lists is likely to produce useful results.

/a

Hi Adam,

    I'm a bit concerned about the optics of what just happened.
  • The Working Group has been pushing for the use of SDP since 2011 (see http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html).
  • The first post related to the use of SDP in WebRTC came from Christer Holmberg of Ericsson on September 14th, 2011.
  • One of the Chairs of the Working Group and one of the Specification editors are from Ericsson.
  • There has been a substantial push against the use of SDP by some mailing list participants, but this was rejected by the Working Group.
  • Suddenly we find out that Ericsson has filed two patents related to the use of SDP in WebRTC and these were filed *after* Ericsson actively pushed for the use of SDP.

    Isn't there a conflict of interest here?

    As a Web Developer who doesn't want/need SDP to begin with, I am finding this a bitter pill to swallow. I have no problem with other people using SDP (all the power to them) but, with this IPR discovery, forcing their preference on me will have real-world consequences (no less than had we mandated the use H264 in WebRTC).
  1. Do the patents imply that Web Developers will have to pay patents when deploying application on top of the Browser or Native APIs?
  2. Is there a way to retrofit the API so those of us who do not want/need to use SDP are not forced to license this IPR? For example, the specification states that the initial offer/answer mechanism is out of scope. Could we do the same for SDP?
Thank you,
Gili
--------------060605090502050100050201-- From ted.ietf@gmail.com Tue Jul 23 15:08:35 2013 Return-Path: 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 9382011E8150 for ; Tue, 23 Jul 2013 15:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 W6BcwEL4hMEP for ; Tue, 23 Jul 2013 15:08:34 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 75AD911E814E for ; Tue, 23 Jul 2013 15:08:34 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id n10so12748354oag.0 for ; Tue, 23 Jul 2013 15:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KtO329zA7O80HbjMK+XvyhGzHw/3Oe7HqQ8pQH+jFx8=; b=tTvbkkgQXxZIKpXBCZjddlUGgr/vz1aVK4p/0Gkh9uNEvPhXsF3hed6Nc7scvhQ3d3 1t24Mjl6GjwH5hv2Er617jkgd2SSezUncJoMwZhLUSDzKSU7XbqWjGuY8W3PG+eqg3ls msEXVPpSGZsd2XWOaID2gV+qdFtaNnPNZsy22agSXiReKcIoopf8xCQtI+KtUru0vkoV 42Ck6XsIdKTVcfkMFe8J3tIkTJwBO4GqM+uPssMZ9JXZes9bFaTWyXkfqdo1J/kVrELc QR7K/gGwtua7mD9c/+cytl4ivq2dWC7jMPxhxbqFjO+sD4vKERAKgaev1vWLg5LW2rjV bNXw== MIME-Version: 1.0 X-Received: by 10.50.164.167 with SMTP id yr7mr88381igb.22.1374617313293; Tue, 23 Jul 2013 15:08:33 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Tue, 23 Jul 2013 15:08:33 -0700 (PDT) In-Reply-To: <51EEFC6B.9090503@bbs.darktech.org> References: <51EEB495.4070404@nostrum.com> <51EEFC6B.9090503@bbs.darktech.org> Date: Tue, 23 Jul 2013 15:08:33 -0700 Message-ID: From: Ted Hardie To: cowwoc Content-Type: multipart/alternative; boundary=089e0122a7fca93cdf04e235084c Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:08:36 -0000 --089e0122a7fca93cdf04e235084c Content-Type: text/plain; charset=ISO-8859-1 Hi Gili, I've snipped some of this, but I want to note that it is not really possible for Adam to clarify this at the moment; like the rest of us, he will have to wait for the folks who filed the patent to clarify the situation. He is listed in the IPR declaration only because he brought the patent to the attention of the IETF, not because he is an inventor or assignee. The IETF patent process has already pointed out (in RFC 4879); please check it for the next steps. thanks, Ted Hardie On Tue, Jul 23, 2013 at 2:58 PM, cowwoc wrote: > > Hi Adam, > > I'm a bit concerned about the optics of what just happened. > > - The Working Group has been pushing for the use of SDP since 2011 > (see http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html). > - The first post related to the use of SDP in WebRTC came from > Christer Holmberg of Ericsson on September 14th, 2011. > - One of the Chairs of the Working Group and one of the Specification > editors are from Ericsson. > - There has been a substantial push against the use of SDP by some > mailing list participants, but this was rejected by the Working Group. > - Suddenly we find out that Ericsson has filed two patents related to > the use of SDP in WebRTC and these were filed *after* Ericsson actively > pushed for the use of SDP. > > Isn't there a conflict of interest here? > As a Web Developer who doesn't want/need SDP to begin with, I am > finding this a bitter pill to swallow. I have no problem with other people > using SDP (all the power to them) but, with this IPR discovery, forcing > their preference on me will have real-world consequences (no less than had > we mandated the use H264 in WebRTC). > > 1. Do the patents imply that Web Developers will have to pay patents > when deploying application on top of the Browser or Native APIs? > 2. Is there a way to retrofit the API so those of us who do not > want/need to use SDP are not forced to license this IPR? For example, the > specification states that the initial offer/answer mechanism is out of > scope. Could we do the same for SDP? > > Thank you, > Gili > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e0122a7fca93cdf04e235084c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Gili,

I've snipped some of this, but I want to note that it i= s not really possible for Adam to clarify this at the moment; like the rest= of us, he will have to wait for the folks who filed the patent to clarify = the situation.=A0=A0 He is listed in the IPR declaration only because he br= ought the patent to the attention of the IETF, not because he is an invento= r or assignee.

The IETF patent process has already pointed out (in RFC 4879); please c= heck it for the next steps.

thanks,

Ted Hardie

On Tue,= Jul 23, 2013 at 2:58 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
=20 =20 =20

Hi Adam,

=A0=A0=A0 I'm a bit concerned about the optics of what just happene= d.
  • The Working Group has been pushing for the use of SDP since 2011 (see http://www.ietf.org/mail-archive/web/r= tcweb/current/mail15.html).
  • The first post related to the use of SDP in WebRTC came from Christer Holmberg of Ericsson on September 14th, 2011.
  • One of the Chairs of the Working Group and one of the Specification editors are from Ericsson.
  • There has been a substantial push against the use of SDP by some mailing list participants, but this was rejected by the Working Group.
  • Suddenly we find out that Ericsson has filed two patents related to the use of SDP in WebRTC and these were filed *after* Ericsson actively pushed for the use of SDP.

=A0=A0=A0 Isn't there a conflict of interest here?

=A0=A0=A0 As a Web Developer who doesn't want/need SDP to begin wit= h, I am finding this a bitter pill to swallow. I have no problem with other people using SDP (all the power to them) but, with this IPR discovery, forcing their preference on me will have real-world consequences (no less than had we mandated the use H264 in WebRTC).
  1. Do the patents imply that Web Developers will have to pay patents when deploying application on top of the Browser or Native APIs?
  2. Is there a way to retrofit the API so those of us who do not want/need to use SDP are not forced to license this IPR? For example, the specification states that the initial offer/answer mechanism is out of scope. Could we do the same for SDP?
Thank you,
Gili

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


--089e0122a7fca93cdf04e235084c-- From cowwoc@bbs.darktech.org Tue Jul 23 15:15:16 2013 Return-Path: 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 6A98F11E815B for ; Tue, 23 Jul 2013 15:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 MElqi4FPsfRm for ; Tue, 23 Jul 2013 15:15:11 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id AC74711E8150 for ; Tue, 23 Jul 2013 15:15:10 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so4635676qcy.4 for ; Tue, 23 Jul 2013 15:15:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=RZooyMQaDOSgpv+K5GS4HQllWSKaV1MqRUZgVfMW8ZA=; b=Hn79SJYhN2RABZVtda1ATsWN/iAUVkps/H+bjt78kbeucEKBnMERBx0BZlIYu/NSq6 ECr1vorZiXZQhwr3utohR4WAlQVXRNBrPY6nwPy9Zt8/8N2h5G+7/6DZ6ZlsTXsafLtk nMq7MHI1lqkmp1fk3FUNyXorZ+8VlL/4GlLVKR67agI21r4PnW3O8AGxLJ0Lt8XAdTdX ZVYIbouVPRFLefJRlcNSMTi/xuvd0XVSJEoJF+R0t3q+GStUmdgN+CuAhUOeMzr5J7q2 hSrz7Q6qzTOMbW1h3eoR9A7JRPxRf2DgYeXiNlUssrthMKhEJpRCTAvwVuXKWhacnND+ 0W3A== X-Received: by 10.49.58.70 with SMTP id o6mr39909205qeq.1.1374617710103; Tue, 23 Jul 2013 15:15:10 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id c4sm6975381qad.0.2013.07.23.15.15.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 15:15:09 -0700 (PDT) Message-ID: <51EF0057.2060801@bbs.darktech.org> Date: Tue, 23 Jul 2013 18:14:47 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Hardie References: <51EEB495.4070404@nostrum.com> <51EEFC6B.9090503@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030708030001000801050905" X-Gm-Message-State: ALoCoQnYh9D9Sc4NQEj4LqEd683MNVB0MPpDAKfo1tp9DmdNHEMgesPQbH4Q0eNx222H03UG+VwI Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:15:16 -0000 This is a multi-part message in MIME format. --------------030708030001000801050905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ted, Thank you for the clarification. In the meantime, Adam (and others) can comment question #2. Gili On 23/07/2013 6:08 PM, Ted Hardie wrote: > Hi Gili, > > I've snipped some of this, but I want to note that it is not really > possible for Adam to clarify this at the moment; like the rest of us, > he will have to wait for the folks who filed the patent to clarify the > situation. He is listed in the IPR declaration only because he > brought the patent to the attention of the IETF, not because he is an > inventor or assignee. > > The IETF patent process has already pointed out (in RFC 4879); please > check it for the next steps. > > thanks, > > Ted Hardie > > On Tue, Jul 23, 2013 at 2:58 PM, cowwoc > wrote: > > > Hi Adam, > > I'm a bit concerned about the optics of what just happened. > > * The Working Group has been pushing for the use of SDP since > 2011 (see > http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html). > * The first post related to the use of SDP in WebRTC came from > Christer Holmberg of Ericsson on September 14th, 2011. > * One of the Chairs of the Working Group and one of the > Specification editors are from Ericsson. > * There has been a substantial push against the use of SDP by > some mailing list participants, but this was rejected by the > Working Group. > * Suddenly we find out that Ericsson has filed two patents > related to the use of SDP in WebRTC and these were filed > *after* Ericsson actively pushed for the use of SDP. > > Isn't there a conflict of interest here? > > As a Web Developer who doesn't want/need SDP to begin with, I > am finding this a bitter pill to swallow. I have no problem with > other people using SDP (all the power to them) but, with this IPR > discovery, forcing their preference on me will have real-world > consequences (no less than had we mandated the use H264 in WebRTC). > > 1. Do the patents imply that Web Developers will have to pay > patents when deploying application on top of the Browser or > Native APIs? > 2. Is there a way to retrofit the API so those of us who do not > want/need to use SDP are not forced to license this IPR? For > example, the specification states that the initial > offer/answer mechanism is out of scope. Could we do the same > for SDP? > > Thank you, > Gili > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------030708030001000801050905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ted,

    Thank you for the clarification.

    In the meantime, Adam (and others) can comment question #2.

Gili

On 23/07/2013 6:08 PM, Ted Hardie wrote:
Hi Gili,

I've snipped some of this, but I want to note that it is not really possible for Adam to clarify this at the moment; like the rest of us, he will have to wait for the folks who filed the patent to clarify the situation.   He is listed in the IPR declaration only because he brought the patent to the attention of the IETF, not because he is an inventor or assignee.

The IETF patent process has already pointed out (in RFC 4879); please check it for the next steps.

thanks,

Ted Hardie

On Tue, Jul 23, 2013 at 2:58 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

Hi Adam,

    I'm a bit concerned about the optics of what just happened.
  • The Working Group has been pushing for the use of SDP since 2011 (see http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html).
  • The first post related to the use of SDP in WebRTC came from Christer Holmberg of Ericsson on September 14th, 2011.
  • One of the Chairs of the Working Group and one of the Specification editors are from Ericsson.
  • There has been a substantial push against the use of SDP by some mailing list participants, but this was rejected by the Working Group.
  • Suddenly we find out that Ericsson has filed two patents related to the use of SDP in WebRTC and these were filed *after* Ericsson actively pushed for the use of SDP.

    Isn't there a conflict of interest here?

    As a Web Developer who doesn't want/need SDP to begin with, I am finding this a bitter pill to swallow. I have no problem with other people using SDP (all the power to them) but, with this IPR discovery, forcing their preference on me will have real-world consequences (no less than had we mandated the use H264 in WebRTC).
  1. Do the patents imply that Web Developers will have to pay patents when deploying application on top of the Browser or Native APIs?
  2. Is there a way to retrofit the API so those of us who do not want/need to use SDP are not forced to license this IPR? For example, the specification states that the initial offer/answer mechanism is out of scope. Could we do the same for SDP?
Thank you,
Gili

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



--------------030708030001000801050905-- From adam@nostrum.com Tue Jul 23 15:21:54 2013 Return-Path: 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 5759511E814F for ; Tue, 23 Jul 2013 15:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 EUTGQ7SdPeUh for ; Tue, 23 Jul 2013 15:21:50 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEFD11E815B for ; Tue, 23 Jul 2013 15:21:45 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6NMLUMb046775 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 17:21:31 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51EF01E5.7090701@nostrum.com> Date: Tue, 23 Jul 2013 17:21:25 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cowwoc References: <51EEB495.4070404@nostrum.com> <51EEFC6B.9090503@bbs.darktech.org> In-Reply-To: <51EEFC6B.9090503@bbs.darktech.org> Content-Type: multipart/alternative; boundary="------------030705050605070309010906" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:21:56 -0000 This is a multi-part message in MIME format. --------------030705050605070309010906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The chairs have asked us not to cross-post. As this pertains to an IETF IPR declaration, I'll speak to it here. I'll note that your response is a vast overreaction at this juncture, as (1) these are merely applications, not granted patents; and (2) Ericsson has not yet indicated their intentions regarding the licensing terms of any patents that may result. In terms of your two questions: I'm not a laywer, so I'm not able to speak to the applicability of the patents in any authoritative fashion. All that I can really say is that I have a reasonable belief that the claims of these applications, if granted, would apply to the draft in question. I will make one factual observation, without any interpretation, from which you can draw your own conclusions: the independent claims of the patent applications in question do not mention SDP. /a On 7/23/13 16:58, cowwoc wrote: > > I'm a bit concerned about the optics of what just happened. > > * The Working Group has been pushing for the use of SDP since 2011 > (see http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html). > * The first post related to the use of SDP in WebRTC came from > Christer Holmberg of Ericsson on September 14th, 2011. > * One of the Chairs of the Working Group and one of the > Specification editors are from Ericsson. > * There has been a substantial push against the use of SDP by some > mailing list participants, but this was rejected by the Working Group. > * Suddenly we find out that Ericsson has filed two patents related > to the use of SDP in WebRTC and these were filed *after* Ericsson > actively pushed for the use of SDP. > > Isn't there a conflict of interest here? > > As a Web Developer who doesn't want/need SDP to begin with, I am > finding this a bitter pill to swallow. I have no problem with other > people using SDP (all the power to them) but, with this IPR discovery, > forcing their preference on me will have real-world consequences (no > less than had we mandated the use H264 in WebRTC). > > 1. Do the patents imply that Web Developers will have to pay patents > when deploying application on top of the Browser or Native APIs? > 2. Is there a way to retrofit the API so those of us who do not > want/need to use SDP are not forced to license this IPR? For > example, the specification states that the initial offer/answer > mechanism is out of scope. Could we do the same for SDP? > > Thank you, > Gili > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030705050605070309010906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
The chairs have asked us not to cross-post. As this pertains to an IETF IPR declaration, I'll speak to it here.

I'll note that your response is a vast overreaction at this juncture, as (1) these are merely applications, not granted patents; and (2) Ericsson has not yet indicated their intentions regarding the licensing terms of any patents that may result.

In terms of your two questions: I'm not a laywer, so I'm not able to speak to the applicability of the patents in any authoritative fashion. All that I can really say is that I have a reasonable belief that the claims of these applications, if granted, would apply to the draft in question.

I will make one factual observation, without any interpretation, from which you can draw your own conclusions: the independent claims of the patent applications in question do not mention SDP.

/a



On 7/23/13 16:58, cowwoc wrote:

    I'm a bit concerned about the optics of what just happened.
  • The Working Group has been pushing for the use of SDP since 2011 (see http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html).
  • The first post related to the use of SDP in WebRTC came from Christer Holmberg of Ericsson on September 14th, 2011.
  • One of the Chairs of the Working Group and one of the Specification editors are from Ericsson.
  • There has been a substantial push against the use of SDP by some mailing list participants, but this was rejected by the Working Group.
  • Suddenly we find out that Ericsson has filed two patents related to the use of SDP in WebRTC and these were filed *after* Ericsson actively pushed for the use of SDP.

    Isn't there a conflict of interest here?

    As a Web Developer who doesn't want/need SDP to begin with, I am finding this a bitter pill to swallow. I have no problem with other people using SDP (all the power to them) but, with this IPR discovery, forcing their preference on me will have real-world consequences (no less than had we mandated the use H264 in WebRTC).
  1. Do the patents imply that Web Developers will have to pay patents when deploying application on top of the Browser or Native APIs?
  2. Is there a way to retrofit the API so those of us who do not want/need to use SDP are not forced to license this IPR? For example, the specification states that the initial offer/answer mechanism is out of scope. Could we do the same for SDP?
Thank you,
Gili


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

--------------030705050605070309010906-- From roman@telurix.com Tue Jul 23 15:56:57 2013 Return-Path: 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 78A8811E8177 for ; Tue, 23 Jul 2013 15:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 GFR5VSabD9Ax for ; Tue, 23 Jul 2013 15:56:53 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by ietfa.amsl.com (Postfix) with ESMTP id B24FB11E8173 for ; Tue, 23 Jul 2013 15:56:45 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so7761834wev.0 for ; Tue, 23 Jul 2013 15:56:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=OIsHo9/snYjxBtMtTIna64xrpjLjRFTjv66RS06bpDU=; b=hWCfXs5vjT4r3WWy6cLWxqusuSIDjJIIrMhd4EDXGtS+PN0z2JjCMHoTrAYnoIPORF ohetbjWKiISddMrcd8IjrNsjZWQmPEMKL9uRqpyRiZU7xIwE8tpv5/PrtdcQKQ1N73HD KHWl+YYVMDz1uaLZL1Af4ZfPPWC9It/z8kN1PWXWKmNodz9MRaYKFagz411ueqqRpGem uAGyKYM6eR2HmpUl1hX5FM+Mt0lIKyi2GSSm4NZuPKxVKolodqbWrl2vsq4qwHrTTmGQ WO4ExR5prxw02ZQEgqVg33vjaAoyzJXZ8yHQh9eHBwUyGTlrzOeO5JAYAp73sanbxdim UJMQ== X-Received: by 10.180.75.80 with SMTP id a16mr656571wiw.3.1374620204741; Tue, 23 Jul 2013 15:56:44 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [2a00:1450:400c:c05::22c]) by mx.google.com with ESMTPSA id fs8sm1548080wib.0.2013.07.23.15.56.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 15:56:44 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so3596068wiw.11 for ; Tue, 23 Jul 2013 15:56:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.85.6 with SMTP id d6mr556280wiz.47.1374620203043; Tue, 23 Jul 2013 15:56:43 -0700 (PDT) Received: by 10.216.221.202 with HTTP; Tue, 23 Jul 2013 15:56:42 -0700 (PDT) In-Reply-To: <51EF01E5.7090701@nostrum.com> References: <51EEB495.4070404@nostrum.com> <51EEFC6B.9090503@bbs.darktech.org> <51EF01E5.7090701@nostrum.com> Date: Tue, 23 Jul 2013 18:56:42 -0400 Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=f46d0442808ee757b304e235b4ec X-Gm-Message-State: ALoCoQk1sBcaNznLxNNjyHXyAiMl+0Yswg+Km9AJCB9tzMXjlrmJ2ZkQU+7MofpzWJs5h5uMNOo3 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:56:57 -0000 --f46d0442808ee757b304e235b4ec Content-Type: text/plain; charset=ISO-8859-1 I did not want to blow this out of proportion. All I wanted to point out that that licensing terms are missing and until the licensing terms are clear this does present a certain risk. I do agree that given current active participation of Ericsson in this list, this risk is likely low. One other thing that I wanted to mention was that some aspects of the unified draft can be adjusted to limit the exposure to the declared IPR. Regards, _____________ Roman Shpount On Tue, Jul 23, 2013 at 6:21 PM, Adam Roach wrote: > The chairs have asked us not to cross-post. As this pertains to an IETF > IPR declaration, I'll speak to it here. > > I'll note that your response is a vast overreaction at this juncture, as > (1) these are merely applications, not granted patents; and (2) Ericsson > has not yet indicated their intentions regarding the licensing terms of any > patents that may result. > > In terms of your two questions: I'm not a laywer, so I'm not able to speak > to the applicability of the patents in any authoritative fashion. All that > I can really say is that I have a reasonable belief that the claims of > these applications, if granted, would apply to the draft in question. > > I will make one factual observation, without any interpretation, from > which you can draw your own conclusions: the independent claims of the > patent applications in question do not mention SDP. > > /a > > > > > On 7/23/13 16:58, cowwoc wrote: > > > I'm a bit concerned about the optics of what just happened. > > - The Working Group has been pushing for the use of SDP since 2011 > (see http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html). > - The first post related to the use of SDP in WebRTC came from > Christer Holmberg of Ericsson on September 14th, 2011. > - One of the Chairs of the Working Group and one of the Specification > editors are from Ericsson. > - There has been a substantial push against the use of SDP by some > mailing list participants, but this was rejected by the Working Group. > - Suddenly we find out that Ericsson has filed two patents related to > the use of SDP in WebRTC and these were filed *after* Ericsson actively > pushed for the use of SDP. > > Isn't there a conflict of interest here? > As a Web Developer who doesn't want/need SDP to begin with, I am > finding this a bitter pill to swallow. I have no problem with other people > using SDP (all the power to them) but, with this IPR discovery, forcing > their preference on me will have real-world consequences (no less than had > we mandated the use H264 in WebRTC). > > 1. Do the patents imply that Web Developers will have to pay patents > when deploying application on top of the Browser or Native APIs? > 2. Is there a way to retrofit the API so those of us who do not > want/need to use SDP are not forced to license this IPR? For example, the > specification states that the initial offer/answer mechanism is out of > scope. Could we do the same for SDP? > > Thank you, > Gili > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d0442808ee757b304e235b4ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I did not want to blow this out of proportion. All I wanted to point out th= at that licensing terms are missing and until the licensing terms are clear= this does present a certain risk. I do agree that given current active par= ticipation of Ericsson in this list, this risk is likely low. One other thi= ng that I wanted to mention was that some aspects of the unified draft can = be adjusted to limit the exposure to the declared IPR.

Regards,
_____________
Roman Shpount


On Tue, Jul 23, 2013 at 6:21 PM, Adam Ro= ach <adam@nostrum.com> wrote:
=20 =20 =20
The chairs have asked us not to cross-post. As this pertains to an IETF IPR declaration, I'll speak to it here.

I'll note that your response is a vast overreaction at this juncture, as (1) these are merely applications, not granted patents; and (2) Ericsson has not yet indicated their intentions regarding the licensing terms of any patents that may result.

In terms of your two questions: I'm not a laywer, so I'm not = able to speak to the applicability of the patents in any authoritative fashion. All that I can really say is that I have a reasonable belief that the claims of these applications, if granted, would apply to the draft in question.

I will make one factual observation, without any interpretation, from which you can draw your own conclusions: the independent claims of the patent applications in question do not mention SDP.

/a




On 7/23/13 16:58, cowwoc wrote:
=20
=A0=A0=A0 I'm a bit concerned about the optics of what just happe= ned.
  • The Working Group has been pushing for the use of SDP since 2011 (see http://www.ietf.org/mail-archive/web= /rtcweb/current/mail15.html).
  • The first post related to the use of SDP in WebRTC came from Christer Holmberg of Ericsson on September 14th, 2011.
  • One of the Chairs of the Working Group and one of the Specification editors are from Ericsson.
  • There has been a substantial push against the use of SDP by some mailing list participants, but this was rejected by the Working Group.
  • Suddenly we find out that Ericsson has filed two patents related to the use of SDP in WebRTC and these were filed *after* Ericsson actively pushed for the use of SDP.

=A0=A0=A0 Isn't there a conflict of interest here?

=A0=A0=A0 As a Web Developer who doesn't want/need SDP to begin w= ith, I am finding this a bitter pill to swallow. I have no problem with other people using SDP (all the power to them) but, with this IPR discovery, forcing their preference on me will have real-world consequences (no less than had we mandated the use H264 in WebRTC).
  1. Do the patents imply that Web Developers will have to pay patents when deploying application on top of the Browser or Native APIs?
  2. Is there a way to retrofit the API so those of us who do not want/need to use SDP are not forced to license this IPR? For example, the specification states that the initial offer/answer mechanism is out of scope. Could we do the same for SDP?
Thank you,
Gili


________________________________________=
_______
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb


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


--f46d0442808ee757b304e235b4ec-- From ekr@rtfm.com Tue Jul 23 16:08:42 2013 Return-Path: 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 6D23711E8163 for ; Tue, 23 Jul 2013 16:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 2JJZhTbKLR4n for ; Tue, 23 Jul 2013 16:08:36 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id E8F9211E8172 for ; Tue, 23 Jul 2013 16:08:35 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id f6so1901797qej.26 for ; Tue, 23 Jul 2013 16:08:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=WKCgDmOS3BK0YU/IdjIjjWxYG17HiF3uq95P5eBMn7g=; b=CPMzh+r8HfvU/QEoMCsZq2XY9d5XuqCeFK8To45XHDbl5h5QKakhy9X14my8Ym7FGe hC0NrcaOa888zMbTWd/LjOIwBMUv0cF/JhYeLdk3XqYhbPHYh6gI2tppNea8U57EMFgM Ho8WE5r3Sg17JLmChWfM2HTe7CVdOLirhRZZMfu3017saDqfa3dr4k9/zcayE/Aut7/u MhW1/zKiU6ERUvpBB0XY1cGGoxZn0xjgC41tS+SKzHwSs5cQAdO/jJ/DlmdbFRP7Rk9L ZyyTdKvZnDEgLwIgt6V1Hla07OnrHeSfTZ0cu/Dr1NTz4nqh95UQ7v9TKglv/hJRgW3w zjQA== X-Received: by 10.229.138.135 with SMTP id a7mr9468157qcu.29.1374620915302; Tue, 23 Jul 2013 16:08:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Tue, 23 Jul 2013 16:07:55 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <51EEB495.4070404@nostrum.com> <51EEFC6B.9090503@bbs.darktech.org> <51EF01E5.7090701@nostrum.com> From: Eric Rescorla Date: Tue, 23 Jul 2013 16:07:55 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=e89a8f6475cf5b97c104e235dffe X-Gm-Message-State: ALoCoQlR4LbAWUJ1poqGY+Yfjwdf9+FLxM9yiL1K3ODeyTagasgh1HOx8z3GypOlm/HWkunkZCmg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:08:42 -0000 --e89a8f6475cf5b97c104e235dffe Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 23, 2013 at 3:56 PM, Roman Shpount wrote: > I did not want to blow this out of proportion. All I wanted to point out > that that licensing terms are missing and until the licensing terms are > clear this does present a certain risk. I do agree that given current > active participation of Ericsson in this list, this risk is likely low. One > other thing that I wanted to mention was that some aspects of the unified > draft can be adjusted to limit the exposure to the declared IPR. > Roman, That seems like something that would be useful if you could lay out in more detail. Best, -Ekr Regards, > _____________ > Roman Shpount > > > On Tue, Jul 23, 2013 at 6:21 PM, Adam Roach wrote: > >> The chairs have asked us not to cross-post. As this pertains to an IETF >> IPR declaration, I'll speak to it here. >> >> I'll note that your response is a vast overreaction at this juncture, as >> (1) these are merely applications, not granted patents; and (2) Ericsson >> has not yet indicated their intentions regarding the licensing terms of any >> patents that may result. >> >> In terms of your two questions: I'm not a laywer, so I'm not able to >> speak to the applicability of the patents in any authoritative fashion. All >> that I can really say is that I have a reasonable belief that the claims of >> these applications, if granted, would apply to the draft in question. >> >> I will make one factual observation, without any interpretation, from >> which you can draw your own conclusions: the independent claims of the >> patent applications in question do not mention SDP. >> >> /a >> >> >> >> >> On 7/23/13 16:58, cowwoc wrote: >> >> >> I'm a bit concerned about the optics of what just happened. >> >> - The Working Group has been pushing for the use of SDP since 2011 >> (see http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html). >> - The first post related to the use of SDP in WebRTC came from >> Christer Holmberg of Ericsson on September 14th, 2011. >> - One of the Chairs of the Working Group and one of the Specification >> editors are from Ericsson. >> - There has been a substantial push against the use of SDP by some >> mailing list participants, but this was rejected by the Working Group. >> - Suddenly we find out that Ericsson has filed two patents related to >> the use of SDP in WebRTC and these were filed *after* Ericsson actively >> pushed for the use of SDP. >> >> Isn't there a conflict of interest here? >> As a Web Developer who doesn't want/need SDP to begin with, I am >> finding this a bitter pill to swallow. I have no problem with other people >> using SDP (all the power to them) but, with this IPR discovery, forcing >> their preference on me will have real-world consequences (no less than had >> we mandated the use H264 in WebRTC). >> >> 1. Do the patents imply that Web Developers will have to pay patents >> when deploying application on top of the Browser or Native APIs? >> 2. Is there a way to retrofit the API so those of us who do not >> want/need to use SDP are not forced to license this IPR? For example, the >> specification states that the initial offer/answer mechanism is out of >> scope. Could we do the same for SDP? >> >> Thank you, >> Gili >> >> >> _______________________________________________ >> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --e89a8f6475cf5b97c104e235dffe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 23, 2013 at 3:56 PM, Roman Shpount &l= t;roman@telurix.com<= /a>> wrote:
I did not want to blow this out of proportio= n. All I wanted to point out that that licensing terms are missing and unti= l the licensing terms are clear this does present a certain risk. I do agre= e that given current active participation of Ericsson in this list, this ri= sk is likely low. One other thing that I wanted to mention was that some as= pects of the unified draft can be adjusted to limit the exposure to the dec= lared IPR.

Roman,

That seems= like something that would be useful if you could lay out in more detail.

Best,
-Ekr

Regards,
_____________
Roman Shpount
=


On Tue, Jul 23, 2013 at 6:21 PM, Adam Ro= ach <adam@nostrum.com> wrote:
=20 =20 =20
The chairs have asked us not to cross-post. As this pertains to an IETF IPR declaration, I'll speak to it here.

I'll note that your response is a vast overreaction at this juncture, as (1) these are merely applications, not granted patents; and (2) Ericsson has not yet indicated their intentions regarding the licensing terms of any patents that may result.

In terms of your two questions: I'm not a laywer, so I'm not = able to speak to the applicability of the patents in any authoritative fashion. All that I can really say is that I have a reasonable belief that the claims of these applications, if granted, would apply to the draft in question.

I will make one factual observation, without any interpretation, from which you can draw your own conclusions: the independent claims of the patent applications in question do not mention SDP.

/a




On 7/23/13 16:58, cowwoc wrote:
=20
=A0=A0=A0 I'm a bit concerned about the optics of what just happe= ned.
  • The Working Group has been pushing for the use of SDP since 2011 (see http://www.ietf.org/mail-archive/web= /rtcweb/current/mail15.html).
  • The first post related to the use of SDP in WebRTC came from Christer Holmberg of Ericsson on September 14th, 2011.
  • One of the Chairs of the Working Group and one of the Specification editors are from Ericsson.
  • There has been a substantial push against the use of SDP by some mailing list participants, but this was rejected by the Working Group.
  • Suddenly we find out that Ericsson has filed two patents related to the use of SDP in WebRTC and these were filed *after* Ericsson actively pushed for the use of SDP.

=A0=A0=A0 Isn't there a conflict of interest here?

=A0=A0=A0 As a Web Developer who doesn't want/need SDP to begin w= ith, I am finding this a bitter pill to swallow. I have no problem with other people using SDP (all the power to them) but, with this IPR discovery, forcing their preference on me will have real-world consequences (no less than had we mandated the use H264 in WebRTC).
  1. Do the patents imply that Web Developers will have to pay patents when deploying application on top of the Browser or Native APIs?
  2. Is there a way to retrofit the API so those of us who do not want/need to use SDP are not forced to license this IPR? For example, the specification states that the initial offer/answer mechanism is out of scope. Could we do the same for SDP?
Thank you,
Gili


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


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



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


--e89a8f6475cf5b97c104e235dffe-- From cowwoc@bbs.darktech.org Tue Jul 23 16:19:57 2013 Return-Path: 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 A28B811E816F for ; Tue, 23 Jul 2013 16:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Zz7002KFJVQW for ; Tue, 23 Jul 2013 16:19:53 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id BC17F11E8163 for ; Tue, 23 Jul 2013 16:19:52 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so4638655qcy.32 for ; Tue, 23 Jul 2013 16:19:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=VzRQWGQMyGwcHScp5Iq3bKW8TL5cc+YQjm2rs7Qow/w=; b=g8jYPoNP4cS8iCKInCahDzllm5N13/XQu8cA6XtacQmLfNbHPoE+cuNyd5zwAWdXnc AwxnU2eDLJSu+d+h7wokfCrrq5lOTKRqcnImss+wpP9Je2JYGcdJze/0u7G2lduyBEc8 nJZq+Mben3K7/EkkmzPW79s3a2JhdwtUHF9M2haMWeTyhI2RUdQ6yPPbGl6VMXhT/TNT ZSpzUPxoho4P+8sZ0R+2HxvpKT8WpzjTbocd4aCzsiOkp4u8YZR94fH0U4Rl+1OCjW35 nuojXy6nIV9I6k8iIechsIKKyBps2bFLOcIq17je+aa4YTHeXcbikmUte0ETSNLlniGM bfDA== X-Received: by 10.49.109.72 with SMTP id hq8mr40716042qeb.38.1374621589998; Tue, 23 Jul 2013 16:19:49 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id i1sm50302359qas.10.2013.07.23.16.19.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 16:19:49 -0700 (PDT) Message-ID: <51EF0F7F.8070201@bbs.darktech.org> Date: Tue, 23 Jul 2013 19:19:27 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Roach References: <51EEB495.4070404@nostrum.com> <51EEFC6B.9090503@bbs.darktech.org> <51EF01E5.7090701@nostrum.com> In-Reply-To: <51EF01E5.7090701@nostrum.com> Content-Type: multipart/alternative; boundary="------------080309060409070206060200" X-Gm-Message-State: ALoCoQnTTxxke2UWaW2ws3usI+eEvteKFIwRQuo2v+7siNt+inl1N5sXNDN8yhnuMLzjn+vNjzg5 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:19:57 -0000 This is a multi-part message in MIME format. --------------080309060409070206060200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adam, On 23/07/2013 6:21 PM, Adam Roach wrote: > The chairs have asked us not to cross-post. As this pertains to an > IETF IPR declaration, I'll speak to it here. I cross-posted because I think we need to have a separate discussion regarding how to mitigate IPR risk in the API. It's good that you removed public-webrtc@w3c.org from the reply (I should have explained as much in my original post). > I'll note that your response is a vast overreaction at this juncture, > as (1) these are merely applications, not granted patents; and (2) > Ericsson has not yet indicated their intentions regarding the > licensing terms of any patents that may result. I am not a lawyer either so I apologize if this seems like an overreaction. Based on my limited knowledge of software patents, I view this as a matter of concern. Furthermore, based on my limited understanding of http://www.ietf.org/rfc/rfc3979.txt I believe that IETF members are required to make IPR disclosures "as soon as reasonably possible after the Contribution is published". My understanding is that Ericsson was responsible to disclose this over 4 months ago (but did not). Again, I apologize if I am misunderstanding the document. Anyway, I'll wait to see what the community has to say. Hopefully we can come up with a reasonable solution. Thanks, Gili > > /a > > > > On 7/23/13 16:58, cowwoc wrote: >> >> I'm a bit concerned about the optics of what just happened. >> >> * The Working Group has been pushing for the use of SDP since 2011 >> (see >> http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html). >> * The first post related to the use of SDP in WebRTC came from >> Christer Holmberg of Ericsson on September 14th, 2011. >> * One of the Chairs of the Working Group and one of the >> Specification editors are from Ericsson. >> * There has been a substantial push against the use of SDP by some >> mailing list participants, but this was rejected by the Working >> Group. >> * Suddenly we find out that Ericsson has filed two patents related >> to the use of SDP in WebRTC and these were filed *after* Ericsson >> actively pushed for the use of SDP. >> >> Isn't there a conflict of interest here? >> >> As a Web Developer who doesn't want/need SDP to begin with, I am >> finding this a bitter pill to swallow. I have no problem with other >> people using SDP (all the power to them) but, with this IPR >> discovery, forcing their preference on me will have real-world >> consequences (no less than had we mandated the use H264 in WebRTC). >> >> 1. Do the patents imply that Web Developers will have to pay patents >> when deploying application on top of the Browser or Native APIs? >> 2. Is there a way to retrofit the API so those of us who do not >> want/need to use SDP are not forced to license this IPR? For >> example, the specification states that the initial offer/answer >> mechanism is out of scope. Could we do the same for SDP? >> >> Thank you, >> Gili >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > --------------080309060409070206060200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Adam,

On 23/07/2013 6:21 PM, Adam Roach wrote:
The chairs have asked us not to cross-post. As this pertains to an IETF IPR declaration, I'll speak to it here.

    I cross-posted because I think we need to have a separate discussion regarding how to mitigate IPR risk in the API. It's good that you removed public-webrtc@w3c.org from the reply (I should have explained as much in my original post).

I'll note that your response is a vast overreaction at this juncture, as (1) these are merely applications, not granted patents; and (2) Ericsson has not yet indicated their intentions regarding the licensing terms of any patents that may result.

    I am not a lawyer either so I apologize if this seems like an overreaction. Based on my limited knowledge of software patents, I view this as a matter of concern. Furthermore, based on my limited understanding of http://www.ietf.org/rfc/rfc3979.txt I believe that IETF members are required to make IPR disclosures "as soon as reasonably possible after the Contribution is published". My understanding is that Ericsson was responsible to disclose this over 4 months ago (but did not). Again, I apologize if I am misunderstanding the document.

    Anyway, I'll wait to see what the community has to say. Hopefully we can come up with a reasonable solution.

Thanks,
Gili


/a



On 7/23/13 16:58, cowwoc wrote:

    I'm a bit concerned about the optics of what just happened.
  • The Working Group has been pushing for the use of SDP since 2011 (see http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html).
  • The first post related to the use of SDP in WebRTC came from Christer Holmberg of Ericsson on September 14th, 2011.
  • One of the Chairs of the Working Group and one of the Specification editors are from Ericsson.
  • There has been a substantial push against the use of SDP by some mailing list participants, but this was rejected by the Working Group.
  • Suddenly we find out that Ericsson has filed two patents related to the use of SDP in WebRTC and these were filed *after* Ericsson actively pushed for the use of SDP.

    Isn't there a conflict of interest here?

    As a Web Developer who doesn't want/need SDP to begin with, I am finding this a bitter pill to swallow. I have no problem with other people using SDP (all the power to them) but, with this IPR discovery, forcing their preference on me will have real-world consequences (no less than had we mandated the use H264 in WebRTC).
  1. Do the patents imply that Web Developers will have to pay patents when deploying application on top of the Browser or Native APIs?
  2. Is there a way to retrofit the API so those of us who do not want/need to use SDP are not forced to license this IPR? For example, the specification states that the initial offer/answer mechanism is out of scope. Could we do the same for SDP?
Thank you,
Gili


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


--------------080309060409070206060200-- From keith.drage@alcatel-lucent.com Tue Jul 23 17:59:37 2013 Return-Path: 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 2D2F111E81A4 for ; Tue, 23 Jul 2013 17:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.57 X-Spam-Level: X-Spam-Status: No, score=-110.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 qEGPFiE7LcIQ for ; Tue, 23 Jul 2013 17:59:31 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACEB11E81A6 for ; Tue, 23 Jul 2013 17:59:30 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6O0xPnt000568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Jul 2013 19:59:27 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6O0xO5P020306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 02:59:24 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 24 Jul 2013 02:59:24 +0200 From: "DRAGE, Keith (Keith)" To: cowwoc , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Unified plan IPR Thread-Index: AQHOh++0jWlPWg1wtE6LFph3rvjdWJly/+yA Date: Wed, 24 Jul 2013 00:59:23 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B071462@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <51EEB495.4070404@nostrum.com> <51EEFC6B.9090503@bbs.darktech.org> In-Reply-To: <51EEFC6B.9090503@bbs.darktech.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B071462FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 00:59:37 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B071462FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In regard to your questions, I suggest you go read RFC 3979 (BCP 79) and it= s updates (as referred to by Adam) and then continue the discussion. In regard to 1, noone in the IETF can tell you anything about the licensing= conditions beyond what is stated in the IPR declaration. RFC 4879 says how= you go about getting more clarity in the declaration if it is required. (B= ut note the requirements of the declaration are limited). In regard to 2, the IETF WG is expected to make its decisions based on know= ledge of declared IPR, and the declared licensing policy. W3C has (very) different IPR rules and you need to have that different disc= ussion there for any requirements specified by W3C. Regards Keith ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= cowwoc Sent: 23 July 2013 22:58 To: rtcweb@ietf.org Cc: public-webrtc@w3.org Subject: Re: [rtcweb] Unified plan IPR On 23/07/2013 12:51 PM, Adam Roach wrote: On 7/23/13 11:22, Roman Shpount wrote: The situation would be a bit clearer if patent holders were to provide the = licensing policy regarding this IPR release. Given that Ericsson is activel= y involved in this working group, I think it would be reasonable to ask the= m for this. If process has been properly followed, the IPR holder has already been noti= fied by the IETF executive director. See http://www.ietf.org/rfc/rfc4879.tx= t (section 1 paragraph 1) I doubt agitating for action on these mailing lists is likely to produce us= eful results. /a Hi Adam, I'm a bit concerned about the optics of what just happened. * The Working Group has been pushing for the use of SDP since 2011 (see= http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html). * The first post related to the use of SDP in WebRTC came from Christer= Holmberg of Ericsson on September 14th, 2011. * One of the Chairs of the Working Group and one of the Specification e= ditors are from Ericsson. * There has been a substantial push against the use of SDP by some mail= ing list participants, but this was rejected by the Working Group. * Suddenly we find out that Ericsson has filed two patents related to t= he use of SDP in WebRTC and these were filed *after* Ericsson actively push= ed for the use of SDP. Isn't there a conflict of interest here? As a Web Developer who doesn't want/need SDP to begin with, I am findin= g this a bitter pill to swallow. I have no problem with other people using = SDP (all the power to them) but, with this IPR discovery, forcing their pre= ference on me will have real-world consequences (no less than had we mandat= ed the use H264 in WebRTC). 1. Do the patents imply that Web Developers will have to pay patents whe= n deploying application on top of the Browser or Native APIs? 2. Is there a way to retrofit the API so those of us who do not want/nee= d to use SDP are not forced to license this IPR? For example, the specifica= tion states that the initial offer/answer mechanism is out of scope. Could = we do the same for SDP? Thank you, Gili --_000_949EF20990823C4C85C18D59AA11AD8B071462FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In regard to your questions, I suggest= you go read RFC 3979 (BCP 7= 9) and its updates (as referred to by Adam) and then continue the discussion.

 

In regard to 1, noone in the IETF can = tell you anything about the licensing conditions beyond what is stated in t= he IPR declaration. RFC 4879 sa= ys how you go about getting more clarity in the declaration if it is requir= ed. (But note the requirements of the declaration are limited).<= /span>

 

In regard to 2, the IETF WG is expecte= d to make its decisions based on knowledge of declared IPR, and the declared licens= ing policy.

 

W3C has (very) different IPR rules and you need to ha= ve that different discussion there for any requirements specified by W3C.

 

Regards

 

Keith

 

= From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
Sent: 23 July 2013 22:58
To: rtcweb@ietf.org
Cc: public-webrtc@w3.org
Subject: Re: [rtcweb] Unifie= d plan IPR

 

On 23/07/2013 12:51 PM, Adam R= oach wrote:

On 7/23/= 13 11:22, Roman Shpount wrote:

The situation would be a bit clearer= if patent holders were to provide the licensing policy regarding this IPR release. Given that Eric= sson is actively involved in this working group, I think it would be reason= able to ask them for this.


If process has been properly followed, the IPR= holder has already been notified by the IETF executive d= irector. See http://www.ietf.org/rfc/rfc= 4879.txt (section 1 paragraph 1)

I doubt agitating for action on these mailing lists is likely to produce us= eful results.

/a


Hi Adam,

    I'm a bit concerned about the optics of what just happen= ed.

  • The Working Group has been pushing for the use of SDP since= 2011 (see http://www.ietf.org/mail-archive/web/rtcweb/current/mail15.html).=
  • The first post related to the use of SDP in WebRTC came fro= m Christer Holmberg of Ericsson on September 14th, 2011.<= /font>
  • One of the Chairs of the Working Group and one of the Speci= fication editors are from Ericsson.
  • There has been a substantial push against the use of SDP by= some mailing list participants, but this was rejected by the Working Group= .
  • Suddenly we find out that Ericsson has filed two patents re= lated to the use of SDP in WebRTC and these were filed *after* Ericsson act= ively pushed for the use of SDP.

    Isn't there a conflict of interest he= re?

    As a Web Develope= r who doesn't want/need SDP to begin with, I am finding this a bitter pill = to swallow. I have no problem with other people using SDP (all the power to them) but, with this IPR discovery, forcing their preference on me will have real-wo= rld consequences (no less than had we mandated the use H264 in WebRTC).

  1. Do the patents imply that Web Developers will have to pay p= atents when deploying application on top of the Browser or Native APIs?
  2. Is there a way to retrofit the API so those of us who do no= t want/need to use SDP are not forced to license this IPR? For example, the specif= ication states that the initial offer/answer mechanism is out of scope. Cou= ld we do the same for SDP?

Thank you,
Gili

--_000_949EF20990823C4C85C18D59AA11AD8B071462FR712WXCHMBA11zeu_-- From fluffy@cisco.com Tue Jul 23 20:28:11 2013 Return-Path: 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 AB6AB11E81CE for ; Tue, 23 Jul 2013 20:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 mPDUUG+u0Xl0 for ; Tue, 23 Jul 2013 20:28:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 27C5911E81C7 for ; Tue, 23 Jul 2013 20:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=753; q=dns/txt; s=iport; t=1374636486; x=1375846086; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=41hIwIKnSZfksIzHM3/B/99JbCUtAI0VJlfXDNjcfUs=; b=OnH8H1hBMkDorEqI99bM1MCc11gHTIRZGC6Zz1GKXceEreRzzNmKibts 4qyhYedG6VfzfUGh7SnhpHXZ7sN/gX5/yWxmCa+IQq/7FrM+CORkvv8Uz bukzhgx+wilB0evDfqIVSO23vyeU6eocQ1cbuZrsarGZEv+xMIRiegIIt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAGVJ71GtJV2a/2dsb2JhbABbgwaBBYJCvj2BFBZ0giUBAQR5EAIBCCIkMiUCBA4FCIgIuCGPRwIxB4MSbgOpLIMUgio X-IronPort-AV: E=Sophos;i="4.89,732,1367971200"; d="scan'208";a="238410081" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jul 2013 03:28:05 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6O3S4mJ014590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 03:28:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 23 Jul 2013 22:28:04 -0500 From: "Cullen Jennings (fluffy)" To: cowwoc Thread-Topic: [rtcweb] Unified plan IPR Thread-Index: AQHOiB3OuqDQS1ow4keRzpHBNABLMg== Date: Wed, 24 Jul 2013 03:28:04 +0000 Message-ID: References: <51EEB495.4070404@nostrum.com> <51EEFC6B.9090503@bbs.darktech.org> <51EF0057.2060801@bbs.darktech.org> In-Reply-To: <51EF0057.2060801@bbs.darktech.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1454C6474E555C409745779FC56331FA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 03:28:11 -0000 On Jul 23, 2013, at 4:14 PM, cowwoc wrote: >> =95 Is there a way to retrofit the API so those of us who do not want/n= eed to use SDP are not forced to license this IPR? For example, the specifi= cation states that the initial offer/answer mechanism is out of scope. Coul= d we do the same for SDP? I think that you should have a read of the patent before deciding what the = best mitigation is. The IETF generally does prefer to avoid IPR where it c= an and some people have been working towards that.=20 I'd also like to note that I far as I can tell right now, Ericsson did make= all the required disclosures promptly. They did disclose all this long ago= when they published their relevant draft.=20 From rajmohanbanavi@gmail.com Tue Jul 23 23:54:37 2013 Return-Path: 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 0C71B11E81FF; Tue, 23 Jul 2013 23:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5v4Ee7YqYGTW; Tue, 23 Jul 2013 23:54:36 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3028611E80E3; Tue, 23 Jul 2013 23:54:36 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so76597oag.32 for ; Tue, 23 Jul 2013 23:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yeAOOUID4SqBHOremPsOvPkkv9C6njiYcfA6HHmeWKk=; b=eC98Q+FKhnP2CLoP1XzDrw3Q1cygqnHgud/kxolLt0KYOt4UWduk7t3qcFI2dk/LoK 0wwqp4b7QfXmKBjgQ3Vi80HnOWkP92y2Cxkf958GfHhsr9gADETp3jREozujhOCSjqn0 93TVszfFTeI23RCEKDOMP8QTTD2D6DkeyRxxZTmlMe9fb/wck02bUVmrG7JyQ/eaGnGQ CgWgc6cLhfDwlWgleAbmIXe2nPjEn8Dsi4lbY9Y5pJ2nex+c+nl+Hd9NxQeEHMHm2j0c iLOhtgHATkQhlXuly1dVJ8WEvw1e/jGZfNPfDvTiwzBr0jHBi1J8WcxF/Rp8HvXWMg5c r8Gw== MIME-Version: 1.0 X-Received: by 10.50.1.78 with SMTP id 14mr244058igk.60.1374648874510; Tue, 23 Jul 2013 23:54:34 -0700 (PDT) Received: by 10.42.96.5 with HTTP; Tue, 23 Jul 2013 23:54:34 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> Date: Wed, 24 Jul 2013 12:24:34 +0530 Message-ID: From: Rajmohan Banavi To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bdc119adb319c04e23c619a Cc: behave , Oleg Moskalenko , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 06:54:37 -0000 --047d7bdc119adb319c04e23c619a Content-Type: text/plain; charset=ISO-8859-1 > So there are two parts to the proposal - the HTTP request for the > credentials and interactions with WebRTC, and the stateless implementation > that avoids the need for communication between web and TURN servers. And it > is true that other implementations besides the suggested stateless one are > possible, e.g. OAuth2. > > Would you prefer that I address the protocol and implementation parts > separately in the document, and mention that other implementations with the > same HTTP protocol are possible? RFC 5766 does something similar, where it > defines the TURN protocol, but in Section 6.2 talks about how a "stateless > stack" implementation can be used to simplify the processing on the TURN > server. > > As you pointed out, the draft essentially has 2 parts - the REST API and the stateless stack implementation which are completely independent. So yes, separating them would help because we want other implementations to also be compliant to the spec. Having said that, I would like opinions and consensus from others as well. Just to make my earlier point clearer - The credentials are generated by TURN server and validated by TURN server. None of the other components in the chain - web server, web application and the webrtc client, are concerned with it (sort of like a blob). So the interoperability is not an issue at all irrespective of what implementation approach you take. I had some other comments earlier, which are collated below. 1. What does the web server do with the shared (with TURN server) secret key? This is not clear from the text. 2. Sec 4.2 Server - "Note that the REALM value supplied by the server is not meaningful in this context, and can be set to any valid value". Which realm value is being referred here? The REALM attribute value in the 401 challenge response sent by the TURN server (in response to initial ALLOCATE request)? 3. The 2 statements seem to be contradictory: sec 1 "However, as a relay service, it imposes a nontrivial cost on the service provider". sec 5.1 "The assumption is that TURN services are of low enough value that waiting for the timeout to expire is a valid approach for dealing with possibly-compromised credentials". I am OK with the text, but would prefer if this could be reworded in anyway. --047d7bdc119adb319c04e23c619a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
So there are two parts to the proposal - the HTTP request = for the credentials and interactions with WebRTC, and the stateless impleme= ntation that avoids the need for communication between web and TURN servers= . And it is true that other implementations besides the suggested stateless= one are possible, e.g. OAuth2.

Would you prefer that I address the protocol and implem= entation parts separately in the document, and mention that other implement= ations with the same HTTP protocol are possible? RFC 5766 does something si= milar, where it defines the TURN protocol, but in Section 6.2 talks about h= ow a "stateless stack" implementation can be used to simplify the= processing on the TURN server.

As you pointe= d out, the draft essentially has 2 parts - the REST API and the stateless s= tack implementation which are completely independent. So yes, separating th= em would help because we want other implementations to also be compliant to= the spec. Having said that, I would like opinions and consensus from other= s as well.

Just to mak= e my earlier point clearer - The credentials are generated by TURN server a= nd validated by TURN server. None of the other components in the chain - we= b server, web application and the webrtc client, are concerned with it (sor= t of like a blob). So the interoperability is not an issue at all irrespect= ive of what implementation approach you take.

I had some = other comments earlier, which are collated below.
  1. What does the web server do with the shared (with TURN serve= r) secret key? This is not clear from the text.
  2. Sec 4.2 Server - "Note that the REALM value supplied by the s= erver is not meaningful in this context, and can be set to any valid value&= quot;. Which realm value is being referred here? The REALM attribute value = in the 401 challenge response sent by the TURN server (in response to initi= al ALLOCATE request)?
  3. The 2 statements seem to be contradictory: sec 1 "However, as= a relay service, it imposes a nontrivial cost on the service provider"= ;. sec 5.1 "The assumption is that TURN services are of low enough val= ue that waiting for the timeout to expire is a valid approach for dealing w= ith possibly-compromised credentials". I am OK with the text, but woul= d prefer if this could be reworded in anyway.
--047d7bdc119adb319c04e23c619a-- From rajmohanbanavi@gmail.com Wed Jul 24 01:47:00 2013 Return-Path: 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 AD39611E83C9; Wed, 24 Jul 2013 01:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9wHi-bAQ4aq9; Wed, 24 Jul 2013 01:47:00 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1A87811E810F; Wed, 24 Jul 2013 01:47:00 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so301168oag.4 for ; Wed, 24 Jul 2013 01:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PEvJv44cQbAZtchg0lSCzitqeXS3fuE+DY/c7cQcivs=; b=rJsEfCva3rPRMglp1moJjiOBrP4CVjnVcvljs1EeTdlQzMbekXHBXRA5cCprnXl1Kc mDTiv2CUyI5K1ANezJSkdubOccH0iMN58kXoyBs0hMJ3q0/9uDEYHe2daO6Kq5E71KFL QDpdyLxjDhJyWpRZVmGtnzgGYb5dqWjwHe9zupTxXlvLR2wekC5zmS0HWXQbmsQFPx0H eEs4axKybjFRdoaxK1UbCJQiZgfUfoGKAwjAFL7L+JzC6CcKq2P8DNUcRgP/Q4OyzIir qcktMwmJXspYrZ++MyKD6/nOZ9L1QYj2m7nZulNgckfuWuDvnxauP+DewdfLi+qcpc3y sXoA== MIME-Version: 1.0 X-Received: by 10.43.0.67 with SMTP id nl3mr19413969icb.2.1374655619586; Wed, 24 Jul 2013 01:46:59 -0700 (PDT) Received: by 10.42.96.5 with HTTP; Wed, 24 Jul 2013 01:46:59 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> Date: Wed, 24 Jul 2013 14:16:59 +0530 Message-ID: From: Rajmohan Banavi To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=bcaec511e1b6e4e6be04e23df36a Cc: behave , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:47:00 -0000 --bcaec511e1b6e4e6be04e23df36a Content-Type: text/plain; charset=ISO-8859-1 This is the draft (BEHAVE WG) I am referring to - http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 > This is not the case. It is not the TURN server who generates the > credentials. The web server must generate the temporary password, and to be > able to do that the web server must have the shared secret - the same as > TURN server has. How they share the same shared secret I'd leave outside > the proposed specs. > > OK fine. > It is rather clear - the web server takes the shared secret and it > generates the temporary password for long-term TURN credentials. The TURN > server can reproduce that generation process and obtain the same temporary > password - because the TURN server knows the same shared secret as the web > server. > OK fine. Thanks, Rajmohan --bcaec511e1b6e4e6be04e23df36a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is the draft (BEHAVE WG) I am referring to -=A0http://tools.ietf.or= g/html/draft-uberti-behave-turn-rest-00


This is not the case. It is not the TURN server who generat= es the credentials. The web server must generate the temporary password, an= d to be able to do that the web server must have the shared secret - the sa= me as TURN server has. How they share the same shared secret I'd leave = outside the proposed specs.

OK fine.
=A0
It is rather clear - the web server takes the shared secret and it generat= es the temporary password for long-term TURN credentials. The TURN server c= an reproduce that generation process and obtain the same temporary password= - because the TURN server knows the same shared secret as the web server.<= br>

<= /div>
OK fine.

Thanks,<= /div>
Rajmohan
--bcaec511e1b6e4e6be04e23df36a-- From stefan.lk.hakansson@ericsson.com Wed Jul 24 02:22:20 2013 Return-Path: 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 7E3AE11E83EF; Wed, 24 Jul 2013 02:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 RS5h71U2NKaE; Wed, 24 Jul 2013 02:22:12 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D1B5411E83E7; Wed, 24 Jul 2013 02:22:11 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-76-51ef9cc21603 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.42.19388.2CC9FE15; Wed, 24 Jul 2013 11:22:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Wed, 24 Jul 2013 11:22:09 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Roman Shpount Thread-Topic: [rtcweb] Unified plan IPR Thread-Index: AQHOh8DTWQouOaWKZ069iwy97wHFxg== Date: Wed, 24 Jul 2013 09:22:09 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C336254@ESESSMB209.ericsson.se> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvre6hOe8DDRa8kLfY83cRu8XU5Y9Z LGZcmMpssfZfO7vFuvfHWBxYPZYs+cnkMWvnExaPW1MKPC5O288UwBLFZZOSmpNZllqkb5fA lfFw8UvWgkuCFcde7GRrYPzO28XIySEhYCJx8cEBJghbTOLCvfVsXYxcHEIChxklFm34A+Us YZT4MfsKM0gVm0CgxNZ9C9hAbBEBVYm/3yczgRQxC/QxSsy70wJWJCygJrG9vYsJokhdonf+ KnYIW0/iZdsCxi5GDg4WoOaP58pAwrwCvhLrn04AKxESCJA48ec62HxGoIu+n1oDNoZZQFzi 1pP5UJcKSCzZc54ZwhaVePn4HyuErSTRuOQJK0S9nsSNqVPYIGxtiWULXzND7BKUODnzCcsE RtFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXm29iBEbPwS2/DXYwbrovdohRmoNFSZx3s96Z QCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MatVuc9xCy9levTJLUtepXpvfpFnob3GR4e5F vl77DPfYSX826f//VKGdxDTb05i1dhuTKntc+MmdHnP+VjenqU/yunybXa7q3+N7e0oXXLpu +p/njvCngtK9MomHdrlFRLHM5verqthyMt3c5sNeOU2LVZuqzG7sFO+ITLpxeLb8uZdFcj1K LMUZiYZazEXFiQCbQT+UbAIAAA== Cc: "rtcweb@ietf.org" , "mmusic@ietf.org" , tim panton Subject: Re: [rtcweb] Unified plan IPR X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:22:20 -0000 FYI,=0A= =0A= I've asked internally in my company for advice on what needs to be done =0A= (if anything) from our side. IPRs and handling of them is outside my =0A= competence.=0A= =0A= Stefan=0A= =0A= =0A= On 7/23/13 6:22 PM, Roman Shpount wrote:=0A= > Changing the title and the mailing list to the more appropriate.=0A= >=0A= > The situation would be a bit clearer if patent holders were to provide=0A= > the licensing policy regarding this IPR release. Given that Ericsson is= =0A= > actively involved in this working group, I think it would be reasonable= =0A= > to ask them for this.=0A= >=0A= > Regards,=0A= > _____________=0A= > Roman Shpount=0A= >=0A= >=0A= > On Tue, Jul 23, 2013 at 11:51 AM, Adam Roach > wrote:=0A= >=0A= > On 7/23/13 09:20, tim panton wrote:=0A= >> On 23 Jul 2013, at 14:00, Stefan H=E5kansson LK wrote:=0A= >>=0A= >>> On 7/23/13 5:03 AM, Justin Uberti wrote:=0A= >>>> With the compromise reached in the Unified Plan document,=0A= >>> Presumablyhttp://www.ietf.org/id/draft-roach-mmusic-unified-plan-00= .txt=0A= >> I'll draw folks attention to this IPR claim=0A= >>=0A= >> https://datatracker.ietf.org/ipr/2141/=0A= >>=0A= >> What does that mean in practice?=0A= >>=0A= >=0A= > In practice, it has very little effect.=0A= >=0A= > For those of you unfamiliar with IETF IPR policy, it is documented=0A= > in RFC 3979:=0A= >=0A= > http://www.ietf.org/rfc/rfc3979.txt=0A= >=0A= > The disclosure Tim points to is made pursuant to section 6.1.3 of=0A= > that document. During the course of developing the unified plan, the= =0A= > applications that are mentioned in that disclosure were brought to=0A= > my attention.=0A= >=0A= > The reason it has little effect in practice is that the independent= =0A= > claims would appear to cover every plan proposal to date (plan a,=0A= > plan b, unified plan, and even all of the "no plan" variations).=0A= > Consequently, it does not benefit any one approach over the others.= =0A= >=0A= > /a=0A= >=0A= >=0A= =0A= From ibc@aliax.net Wed Jul 24 07:09:16 2013 Return-Path: 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 567F511E80E0 for ; Wed, 24 Jul 2013 07:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 asoSCG3Qg+1D for ; Wed, 24 Jul 2013 07:09:11 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8BE21F8203 for ; Wed, 24 Jul 2013 07:09:09 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id q19so5343614qeb.2 for ; Wed, 24 Jul 2013 07:08:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=Rdqupoqvg2CoL+hLz/fAAxu5iNPlT/F+4MukuCTvuMw=; b=ct1Txj+d7k//AdwDSBLEQ4nfjl5sKRo3FkCjpbqhJ2gryA9RkDo4gwi4JMjZBfTznE yizOSz7Ub3I3PUKeCBTZx+JoKekimcPZQ1pWWB9du5QerelPc09c2gcx8I9mnBjyYu/B B7aWiSTvdWl4VOl1uyZ7Vcc4YBjqpX1NUKzzWwmEIFosJQxI265BKhWsB51ZrBiV5220 vp1fRLrEkd62tWVfZmr4db9ktU8HWW3A6MLxRy1Q2UwuTd73pbqEFibQAmApdH/MdQaP 7lwnfuDn3Q0NvWjZcSfB8Ys9OOTm0lGGJf/OSJX+ASb3IuAEHfRyFxuYNiWzBgXodXir O2ZQ== X-Received: by 10.49.117.165 with SMTP id kf5mr1955062qeb.9.1374674917585; Wed, 24 Jul 2013 07:08:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 24 Jul 2013 07:08:17 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 24 Jul 2013 16:08:17 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl0n8GpyMlQUTMR7AdvDH/su82EQpCy5wDOrZvGl/pMBKGX+qyIKzXe7AxXM9FpSKyNzs+d Subject: [rtcweb] About unified Plan and multiple m lines X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:09:16 -0000 Hi, let's suppose WebRTC 1.0 borns with "Unified Plan" built-in, and my browser receives a session invitation from a conference server, and there are 8 audio participants in the conference. So the SDP I receive has 8 "m=3Daudio" lines, maybe with different audio codecs in each line. And following SDP O/A rules my browser will generate SDP answer that will also contain 8 "m=3Daudio" lines. Now, where it is supposed my browser will send my single audio track to the conference server? What does it mean that I receive 8 "m=3Daudio" lines while I'm just able to send a single audio track? which m=3Daudio line should I use for sending RTP? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ekr@rtfm.com Wed Jul 24 07:30:01 2013 Return-Path: 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 3165121F867B for ; Wed, 24 Jul 2013 07:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.226 X-Spam-Level: X-Spam-Status: No, score=-103.226 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 UaRnML-eZSaV for ; Wed, 24 Jul 2013 07:29:55 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 037AD11E8108 for ; Wed, 24 Jul 2013 07:29:42 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so320397qcy.4 for ; Wed, 24 Jul 2013 07:29:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=HKRowbN8wV7Fw3mDfGb08tcqKhnNHCoQGhbyl4pEBLU=; b=SoVDovYZKRxpjo0JmBvdIdNxIrQgpI2DXRtJzOFc19jhlPyOMB6IsUUA5+SLWUkQHd MIWSIdF4OVa1SUhJ2Gx8JG1zTPI6r8WMg/JzhQfIlBFxS8QqlhatnpDOypSBSdYc2mmh GZK9XZcHB2+IVjju1As72go28am5NzkE+s3IRTFtiAlvf6wkgu+4r8WWhFkALtfMBPHO QMtAAOdKx9DeAf3gXaYhe+n/y6XpTdbMAdrdHauf1xvLNqWlnPlQETVhJ62H2/MQZVoL MsjtxrD6QuNYp0UIMwB93VnVM6lR5YMTHcg3VBs0q1CW12QK3QYQrNP7Xo3W8Vm8cnqw E6eQ== X-Received: by 10.49.35.233 with SMTP id l9mr44712772qej.23.1374676181364; Wed, 24 Jul 2013 07:29:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 24 Jul 2013 07:29:01 -0700 (PDT) X-Originating-IP: [74.95.2.170] In-Reply-To: References: From: Eric Rescorla Date: Wed, 24 Jul 2013 07:29:01 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b671fa678c41e04e242bd65 X-Gm-Message-State: ALoCoQkUllSXEfQRwg9VVhGhLJJWLZ7VBozVtGL6aRZGf/9abwn2agAZtlxCWslciqAszBKYiJrY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] About unified Plan and multiple m lines X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:30:01 -0000 --047d7b671fa678c41e04e242bd65 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 7:08 AM, I=F1aki Baz Castillo wrote= : > Hi, let's suppose WebRTC 1.0 borns with "Unified Plan" built-in, and > my browser receives a session invitation from a conference server, and > there are 8 audio participants in the conference. > > So the SDP I receive has 8 "m=3Daudio" lines, maybe with different audio > codecs in each line. And following SDP O/A rules my browser will > generate SDP answer that will also contain 8 "m=3Daudio" lines. > > Now, where it is supposed my browser will send my single audio track > to the conference server? What does it mean that I receive 8 "m=3Daudio" > lines while I'm just able to send a single audio track? which m=3Daudio > line should I use for sending RTP? > One of them will be a=3Dsendrecv. The others will be a=3Dsendonly. The sendrecv line is the one you use to send media. -Ekr --047d7b671fa678c41e04e242bd65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 24, 2013 at 7:08 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
Hi, let's suppose WebRTC 1.0 borns with = "Unified Plan" built-in, and
my browser receives a session invitation from a conference server, and
there are 8 audio participants in the conference.

So the SDP I receive has 8 "m=3Daudio" lines, maybe with differen= t audio
codecs in each line. And following SDP O/A rules my browser will
generate SDP answer that will also contain 8 "m=3Daudio" lines.
Now, where it is supposed my browser will send my single audio track
to the conference server? What does it mean that I receive 8 "m=3Daudi= o"
lines while I'm just able to send a single audio track? which m=3Daudio=
line should I use for sending RTP?

One = of them will be a=3Dsendrecv. The others will be a=3Dsendonly.
Th= e sendrecv line is the one you use to send media.

-Ekr
=A0
--047d7b671fa678c41e04e242bd65-- From ted.ietf@gmail.com Wed Jul 24 09:44:49 2013 Return-Path: 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 6A75511E8219 for ; Wed, 24 Jul 2013 09:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 msoaQVfjEI4E for ; Wed, 24 Jul 2013 09:44:47 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 768D011E8151 for ; Wed, 24 Jul 2013 09:44:47 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k14so1508376oag.26 for ; Wed, 24 Jul 2013 09:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=q1YblubB5bm0XKXy+oA5qsezQ9q0cAuLxTCZ8iQh7F8=; b=cEcyo/YlIjnZzR62mZhQfgSRsm4nTmt4PeyKDZ+lVdzFFME3F7uZBgxuBQDG5gz79G lfyiVmmFZSo8NA5fua2cj9QstDy0D8Lxx6Lex/awqeuNrU0v1lQqzMR9X9neZfV4wh/m pwxoLp9oCGFKV3y7Pdq4L0AViKMNtbmAnZ4/3xiJ6AX4G7SqQ58wtc2mqAjjq0ld+sWR 2BQVFl0+zDGTctxsOpNlDaVgtlI++2VoXR7JORau7SMjoInpCh3jqqM7t3x2iHx7vBp4 CqjtA2IxT9oS3D7qsXTtDlnM9dzpkGVMipKrfGZE/BU3fZ8lWebtc8hg5NZOqTgbOSaF nqGA== MIME-Version: 1.0 X-Received: by 10.42.52.6 with SMTP id h6mr19560801icg.5.1374684283988; Wed, 24 Jul 2013 09:44:43 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Wed, 24 Jul 2013 09:44:43 -0700 (PDT) Date: Wed, 24 Jul 2013 09:44:43 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf3036361f6cef7404e244a044 Subject: [rtcweb] Document review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:44:49 -0000 --20cf3036361f6cef7404e244a044 Content-Type: text/plain; charset=ISO-8859-1 Howdy, Just a reminder to folks that review of the updated documents prior to the meeting will help us make progress. Please make sure that you have read the unified plan document before the MMUSIC session, the data channel docs prior to our session, and the updates to the security docs. List discussion on the documents is, of course, welcome now. https://datatracker.ietf.org/doc/draft-roach-mmusic-unified-plan/ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ Thanks, Ted --20cf3036361f6cef7404e244a044 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howdy,

Just a reminder to folks that review of the updated documents= prior to the meeting will help us make progress.=A0 Please make sure that = you have read the unified plan document before the MMUSIC session, the data= channel docs prior to our session, and the updates to the security docs.= =A0 List discussion on the documents is, of course, welcome now.

https://datatracker.ietf.org/doc/draft-roach-mmusic-unified-plan/
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-ar=
ch/

ht=
tps://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/

htt=
ps://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/Thanks,

Ted


--20cf3036361f6cef7404e244a044--

From fineberg@vline.me  Wed Jul 24 10:08:31 2013
Return-Path: 
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 7F48811E814B for ; Wed, 24 Jul 2013 10:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 sBm6JQqRuGlL for ; Wed, 24 Jul 2013 10:08:27 -0700 (PDT)
Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEBC11E8243 for ; Wed, 24 Jul 2013 10:08:26 -0700 (PDT)
Received: by mail-pb0-f41.google.com with SMTP id rp16so10009536pbb.0 for ; Wed, 24 Jul 2013 10:08:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=kzFjS8rBEitbb8WFI/eV3xjweZ6I4U5R7WweBP81QzM=; b=UbG92p35dxRv7b/LdwdFEdQc+nfsxggY38aGjzfmUh7++tZNN8IuSet7GOugs3CQnH NZva3DI/wTVIRUS8okbUJs/MUBPR43xSJNFs9Zj5Q2QyGQXiuXBxaZ8ijTkD6+SSM/d7 AVT5kVyMLcl5/9dzPr6oMri5NSnurIzR/0D3xKmFrnWZu0Uz2seyXjjXpDxDRl0yPFwF Pc5po25lU/pztQN91Fhaz7JnmLcQWIy1QRHxWw9jKIm3g1xbexaCULj+zZTwLBRc3e/I N+jnLieWOytc0uAZF7H1EjErKXyztchmvWFcbCjAof8gE83fWw3QUZggKS9eGqaj4NS+ 6Wfg==
X-Received: by 10.67.21.229 with SMTP id hn5mr44856320pad.135.1374685704639; Wed, 24 Jul 2013 10:08:24 -0700 (PDT)
Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id wf7sm52553503pac.20.2013.07.24.10.08.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 10:08:23 -0700 (PDT)
Message-ID: <51F00A02.3060204@vline.me>
Date: Wed, 24 Jul 2013 10:08:18 -0700
From: Adam Fineberg 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Bernard Aboba 
References: , <51EEA709.2020009@vline.me> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010308000106040700070801"
X-Gm-Message-State: ALoCoQmPmmYO7QRmkt1PCF+Flmw19uzv/NwQsb8R5RtjKcmz7IyL+9kHkrvZqcMrch+1hdwgj2Co
Cc: "avtext@ietf.org" , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2013 17:08:31 -0000

This is a multi-part message in MIME format.
--------------010308000106040700070801
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Bernard,

I apologize if I come across as being difficult here but I stil am not 
seeing the benefits.  Since the fields are not the same for the codecs, 
we will be multiplexing the bits and that seems to me to add complexity 
rather than add clarity.  Also, I can't find an IETF VP9 document for 
the payload format to reference.  If the group thinks generalization is 
the right approach I would appreciate some collaboration on getting the 
right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:
> I do not think it is necessary to "support all forms of scalability 
> for all codecs".   In fact, I would make that an explicit "non-goal".  
> All that was suggested is to try to create a single extension that 
> supports a few common cases. If it is possible to handle VP8, VP9 and 
> H.264/SVC in a single extension that would be sufficient.  So why not 
> limit it to that?
>
> ------------------------------------------------------------------------
> Date: Tue, 23 Jul 2013 08:53:45 -0700
> From: fineberg@vline.me
> To: stewe@stewe.org
> CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ietf.org; 
> rtcweb@ietf.org
> Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for 
> draft-fineberg-avtext-temporal-layer-ext-00.txt
>
> I've been thinking about this and given the ease at which RFC5285 
> allows for the specification of a header extension and the complexity 
> introduced by trying to generalize the header extension to support all 
> forms of scalability for all codecs that the generalization might not 
> be the best approach.  I'm not sure what we really gain by trying to 
> capture all this in a single header extension rather than one per that 
> can succinctly explain the fields without the complexity of 
> multiplexing the bits.
>
> Thoughts?
>
> Regards,
> Adam
>
> On 7/19/13 3:44 PM, Stephan Wenger wrote:
>
>     Hi,
>
>     From: Adam Fineberg >
>     Date: Friday, 19 July, 2013 15:12
>     To: Stephan Wenger >
>     Cc: Justin Uberti      >, Bernard Aboba
>     >,
>     "avtext@ietf.org "      >, "rtcweb@ietf.org
>     " >
>     Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for
>     draft-fineberg-avtext-temporal-layer-ext-00.txt
>
>     Stephan,
>
>     Thanks for the info and the reference.  I'm not sure I follow as
>     I'm not at all familiar with H.265.  I'll review the reference and
>     see what I can figure.
>
>     StW: Good luck :-)
>
>     It seems though to me that you are suggesting that except in the
>     simple case, that the data for H.265 would not be well suited to a
>     header extension, am I understanding you correctly?  There is no
>     reason the middlebox couldn't get out of band signaling of the VPS
>     as you mention but that would not be within the scope of this
>     header extension.
>
>     StW: well, if you would copy the layer_id into your header
>     extension (just as you need to do for the simple case), a really
>     smart middle box could use this information just as a decoder uses
>     it, assuming that it intercepted the VPS in the first place.
>      Insofar, I wouldn't rule out the second option on technical
>     grounds.  Whether any of the actual products would bother to do
>     that, ever, is another question.  I think the case ought to be
>     documented, though.  I can help drafting text.
>     While we are at it: doing this right could mean that you need
>     multiple specs.  First, a generic header extension mechanism
>     dedicated to side information required for pruning of RTP packet
>     streams—ideally not only for scalable video, although that is the
>     main customer today.  And second, for each "payload" (at present
>     we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including
>     scalable and 3D extensions, which are not yet finalized), VP8, and
>     VP9 (I know little about the latter), plus Daala, and whatnot) a
>     mapping of the bits available in the generic header extension to
>     the bits in the payload itself (NAL header and VPS in case of
>     H.265, NALU header in SVC, and the fields you mention for VP8).
>
>     Stephan
>
>
>     Any insights are appreciated.
>
>     Regards,
>     Adam
>
>     On 7/19/13 8:33 AM, Stephan Wenger wrote:
>
>         Hi,
>         I also believe that 16 bits should be enough.  For H.264 and
>         VP8 that has already been demonstrated.  For H.265, some
>         initial thoughts below.  Apologies for the word-count.
>
>         The scalable version of H265 (called SHVC) is currently under
>         development.  The current working draft can be found here:
>         http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.
>          Therein, the options for defining layering structures are
>         considerably more complex.  To start, we have 3 bits for the
>         temporal ID in the NAL unit header of the H.265 version 1
>         (HEVC) base specification (temporal scalability is already
>         nicely supported in version 1).  Just like in SVC.  In the
>         scalable extension, the NAL unit header contains a six bit
>         field that points into a data structure known as "Video
>         Parameter Set" (VPS).  Inside the VPS, those six bits are
>         mapped to to a position in a directed graph (specified through
>         "dimension_id[][]"), which tells you about the reference
>         relationship of the layer in question and its parent layer.
>          One can recursively follow the graph to determine what used
>         to be called dependency_id, quality_id, view_id, and whatnot.
>          The six bit pointer field can (or: is to be when possible)
>         organized by the encoder such that it is prudent for a middle
>         box to throw away NAL units (belonging to layers) with higher
>         values of the six bit field first, before throwing away NAL
>         units with lower values.  Relying on this feature, 3+6 bits ==
>         9 bits should be fine for the header extension.
>
>         That said, the ordering by the encoder is just a
>         recommendation, and there may well be cases where different
>         pruning strategies may be advisable.  For example, a layering
>         structure could be constructed that expands into two branches,
>         one using 2D scalable tools only, the other including view_id
>         for multi view coding.  By looking at the six bit field alone,
>         a middle box will not be able to meaningfully remove NAL units
>         belonging to one of the branches completely while pruning the
>         other branch.  In order to meaningfully deal with that
>         scenario, there would be two options: one to represent the
>         dimension_id[][] (and associated control info) in the header
>         extension, or require the middle box to have access to the VPS
>         and be able to interpret its content.  The further could take
>         considerably more than 16 bits and we would be talking about a
>         variable length data structure.  The latter requires the
>         middle box to have state and a mechanism to intercept the VPS
>         (through signaling—as the encrypted in-band VPS would not be
>         useful under the assumption that the middle box does not have
>         the key to the media—which is the motivation of the draft in
>         the first place).  I personally don't mind at all the second
>         mechanism, as I'm a big fan of out-of-band parameter set
>         transmission and any middle box must be in the signaling path
>         anyway to meaningfully manipulate RTP.  I do not like the
>         first option due to its variable, and possibly substantial,
>         overhead.
>
>         Stephan
>
>
>         From: Justin Uberti          >
>         Date: Friday, 19 July, 2013 06:32
>         To: Bernard Aboba          >
>         Cc: "avtext@ietf.org "
>         >, "rtcweb@ietf.org
>         "          >
>         Subject: Re: [rtcweb] Fwd: New Version Notification for
>         draft-fineberg-avtext-temporal-layer-ext-00.txt
>
>         Agree those are the right codecs to design for. Since in each
>         case there are fairly low limits on the number of supported
>         layers (i.e. 3 spatial layers for SVC), I think it should be
>         possible to pack the temporal, spatial, quality layer ids into
>         16 bits.
>
>
>         On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba
>         >
>         wrote:
>
>             If we can support VP8/9 as well as H.264/5 SVC
>             that would be a start. It seems doable to me.
>
>             On Jul 18, 2013, at 8:34 PM, "Adam Fineberg"
>             > wrote:
>
>                 Bernard,
>
>                 Are there other codecs you are thinking should be
>                 supported?  If it's generalized I would think we want
>                 to be able to cover all known scalable codecs. I'll
>                 look into the H264/SVC fields to see how to encode
>                 them in a generalized header.
>
>                 Regards,
>                 Adam
>
>                 On 7/18/13 7:40 PM, Bernard Aboba wrote:
>
>                     I think it may be possible to generalize this. 
>                     For example, for H.264/SVC which can support
>                     temporal, spatial and quality scalability, you
>                     would need the quality_id and dependency_id in
>                     addition to the temporal_id (what you call the
>                     temporal layer index).
>
>                     ------------------------------------------------------------------------
>                     Date: Thu, 18 Jul 2013 08:45:38 -0700
>                     From: fineberg@vline.me 
>                     To: bernard_aboba@hotmail.com
>                     
>                     CC: rtcweb@ietf.org ;
>                     avtext@ietf.org 
>                     Subject: Re: [rtcweb] Fwd: New Version
>                     Notification for
>                     draft-fineberg-avtext-temporal-layer-ext-00.txt
>
>                     Bernard,
>
>                     Good question.  I'm not familiar enough with the
>                     parameter requirements of all other scalable
>                     codecs to be able to generalize.  If you'd like to
>                     help specify them, I'd be fine revising the draft
>                     to generalize.
>
>                     Regards,
>                     Adam
>
>                     On 7/17/13 8:26 PM, Bernard Aboba wrote:
>
>                         Since the need is not codec specific (e.g. it
>                         arises with any codec supporting temporal,
>                         spatial and quality scalability), why
>                          a VP8-specific RTP extension?
>
>                         ------------------------------------------------------------------------
>                         Date: Wed, 17 Jul 2013 17:09:46 -0700
>                         From: fineberg@vline.me 
>                         To: rtcweb@ietf.org 
>                         Subject: [rtcweb] Fwd: New Version
>                         Notification for
>                         draft-fineberg-avtext-temporal-layer-ext-00.txt
>
>                         Hi,
>
>                         I'm working on WebRTC services and have found
>                         that while developing services that forward
>                         VP8 video streams if we want to take advantage
>                         of the VP8 temporal scaling we must get the
>                         temporal layer information from the RTP header
>                         which requires us to decrypt the SRTP packets.
>                         This is undesirable both because the
>                         middle-box needs to have access to the keys as
>                         well as the because of the added overhead of
>                         the decrypt/encrypt cycle. This draft proposes
>                         an RTP header extension that will allow us to
>                         use the VP8 temporal layer information
>                         included in the header extension and therefore
>                         do forwarding without SRTP decryption.
>                         Comments welcome.
>
>                         Regards,
>                         Adam Fineberg
>                         fineberg at vline.com
>                         
>
>                         -------- Original Message --------
>                         Subject: 	New Version Notification for
>                         draft-fineberg-avtext-temporal-layer-ext-00.txt
>                         Date: 	Tue, 09 Jul 2013 10:02:05 -0700
>                         From: 	internet-drafts at ietf.org
>                         
>                         To: 	Adam Fineberg
>                         
>
>
>
>                         A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
>                         has been successfully submitted by Adam Fineberg and posted to the
>                         IETF repository.
>
>                         Filename:	 draft-fineberg-avtext-temporal-layer-ext
>                         Revision:	 00
>                         Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
>                         Creation date:	 2013-07-08
>                         Group:		 Individual Submission
>                         Number of pages: 6
>                         URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
>                         Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
>                         Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00
>
>
>                         Abstract:
>                             This document defines a mechanism by which packets of Real-Time
>                             Tranport Protocol (RTP) video streams encoded with the VP8 codec can
>                             indicate, in an RTP header extension, the temporal layer information
>                             about the frame encoded in the RTP packet.  This information can be
>                             used in a middlebox performing bandwidth management of streams
>                             without requiring it to decrypt the streams.
>
>
>                         _______________________________________________ rtcweb
>                         mailing list rtcweb@ietf.org
>                         
>                         https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>                     -- 
>                     Regards,
>                     Adam
>
>
>
>             _______________________________________________
>             rtcweb mailing list
>             rtcweb@ietf.org 
>             https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>         _______________________________________________
>         avtext mailing list
>         avtext@ietf.org  https://www.ietf.org/mailman/listinfo/avtext
>
>
>     -- 
>     Regards,
>     Adam
>
>
> -- 
> Regards,
> Adam

-- 
Regards,
Adam


--------------010308000106040700070801
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Bernard,

    

    I apologize if I come across as being difficult here but I stil am
    not seeing the benefits.  Since the fields are not the same for the
    codecs, we will be multiplexing the bits and that seems to me to add
    complexity rather than add clarity.  Also, I can't find an IETF VP9
    document for the payload format to reference.  If the group thinks
    generalization is the right approach I would appreciate some
    collaboration on getting the right bit definitions for the other
    codecs.

    

    Regards,

    Adam

    

    
On 7/23/13 12:07 PM, Bernard Aboba
      wrote:

    

    

      
      
I do not think it is necessary to "support all
        forms of scalability for all codecs".   In fact, I would make
        that an explicit "non-goal".  All that was suggested is to try
        to create a single extension that supports a few common cases.  
        If it is possible to handle VP8, VP9 and H.264/SVC in a single
        extension that would be sufficient.  So why not limit it to
        that? 

        

        

          
Date: Tue, 23 Jul 2013 08:53:45 -0700

          From: fineberg@vline.me

          To: stewe@stewe.org

          CC: juberti@google.com; bernard_aboba@hotmail.com;
          avtext@ietf.org; rtcweb@ietf.org

          Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification
          for draft-fineberg-avtext-temporal-layer-ext-00.txt

          

          I've been thinking about this and given the ease at which
          RFC5285 allows for the specification of a header extension and
          the complexity introduced by trying to generalize the header
          extension to support all forms of scalability for all codecs
          that the generalization might not be the best approach.  I'm
          not sure what we really gain by trying to capture all this in
          a single header extension rather than one per that can
          succinctly explain the fields without the complexity of
          multiplexing the bits.

          

          Thoughts?

          

          Regards,

          Adam

          

          
On 7/19/13 3:44 PM, Stephan
            Wenger wrote:

          

          

            
Hi,

            
 

            

            
              
 From: Adam Fineberg
                <fineberg@vline.me>

                Date: Friday, 19
                July, 2013 15:12 

                To: Stephan
                Wenger <stewe@stewe.org>

                Cc: Justin
                Uberti <juberti@google.com>,

                Bernard Aboba <bernard_aboba@hotmail.com>,

                "avtext@ietf.org"
                <avtext@ietf.org>,
                "rtcweb@ietf.org"
                <rtcweb@ietf.org>

                Subject: Re:
                [avtext] [rtcweb] Fwd: New Version Notification for
                draft-fineberg-avtext-temporal-layer-ext-00.txt

              

              


              

              

                
Stephan,

                  

                  Thanks for the info and the reference.  I'm not sure I
                  follow as I'm not at all familiar with H.265.  I'll
                  review the reference and see what I can figure. 

              

            
            
 

            

            
StW: Good luck :-)  

            
 

            

            
              

                
It seems though to me that you are suggesting that
                  except in the simple case, that the data for H.265
                  would not be well suited to a header extension, am I
                  understanding you correctly?  There is no reason the
                  middlebox couldn't get out of band signaling of the
                  VPS as you mention but that would not be within the
                  scope of this header extension.

              

            
            
 

            

            
StW:

                  well, if you would copy the layer_id into your header
                  extension (just as you need to do for the simple
                  case), a really smart middle box could use this
                  information just as a decoder uses it, assuming that
                  it intercepted the VPS in the first place.  Insofar, I
                  wouldn't rule out the second option on technical
                  grounds.  Whether any of the actual products would
                  bother to do that, ever, is another question.  I think
                  the case ought to be documented, though.  I can help
                  drafting text.

            
While

                  we are at it: doing this right could mean that you
                  need multiple specs.  First, a generic header
                  extension mechanism dedicated to side information
                  required for pruning of RTP packet streams—ideally not
                  only for scalable video, although that is the main
                  customer today.  And second, for each "payload" (at
                  present we are talking about H.264/SVC, H.265v1
                  (HEVC), H.265v2 (including scalable and 3D extensions,
                  which are not yet finalized), VP8, and VP9 (I know
                  little about the latter), plus Daala, and whatnot) a
                  mapping of the bits available in the generic header
                  extension to the bits in the payload itself (NAL
                  header and VPS in case of H.265, NALU header in SVC,
                  and the fields you mention for VP8).

            


            

            
Stephan

            
              

                


                  

                  Any insights are appreciated.

                  

                  Regards,

                  Adam

                  

                  
On 7/19/13 8:33 AM,
                    Stephan Wenger wrote:

                  

                  

                    
Hi,

                    
I also believe that 16 bits should be enough.
                       For H.264 and VP8 that has already been
                      demonstrated.  For H.265, some initial thoughts
                      below.  Apologies for the word-count.

                    


                    

                    
The scalable version of H265 (called SHVC) is
                      currently under development.  The current working
                      draft can be found here: http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.
                       Therein, the options for defining layering
                      structures are considerably more complex.  To
                      start, we have 3 bits for the temporal ID in the
                      NAL unit header of the H.265 version 1 (HEVC) base
                      specification (temporal scalability is already
                      nicely supported in version 1).  Just like in SVC.
                       In the scalable extension, the NAL unit header
                      contains a six bit field that points into a data
                      structure known as "Video Parameter Set" (VPS).
                       Inside the VPS, those six bits are mapped to to a
                      position in a directed graph (specified through
                      "dimension_id[][]"), which tells you about the
                      reference relationship of the layer in question
                      and its parent layer.  One can recursively follow
                      the graph to determine what used to be called
                      dependency_id, quality_id, view_id, and whatnot.
                       The six bit pointer field can (or: is to be when
                      possible) organized by the encoder such that it is
                      prudent for a middle box to throw away NAL units
                      (belonging to layers) with higher values of the
                      six bit field first, before throwing away NAL
                      units with lower values.  Relying on this feature,
                      3+6 bits == 9 bits should be fine for the header
                      extension.

                    


                    

                    
That said, the ordering by the encoder is just
                      a recommendation, and there may well be cases
                      where different pruning strategies may be
                      advisable.  For example, a layering structure
                      could be constructed that expands into two
                      branches, one using 2D scalable tools only, the
                      other including view_id for multi view coding.  By
                      looking at the six bit field alone, a middle box
                      will not be able to meaningfully remove NAL units
                      belonging to one of the branches completely while
                      pruning the other branch.  In order to
                      meaningfully deal with that scenario, there would
                      be two options: one to represent the
                      dimension_id[][] (and associated control info) in
                      the header extension, or require the middle box to
                      have access to the VPS and be able to interpret
                      its content.  The further could take considerably
                      more than 16 bits and we would be talking about a
                      variable length data structure.  The latter
                      requires the middle box to have state and a
                      mechanism to intercept the VPS (through
                      signaling—as the encrypted in-band VPS would not
                      be useful under the assumption that the middle box
                      does not have the key to the media—which is the
                      motivation of the draft in the first place).  I
                      personally don't mind at all the second mechanism,
                      as I'm a big fan of out-of-band parameter set
                      transmission and any middle box must be in the
                      signaling path anyway to meaningfully manipulate
                      RTP.  I do not like the first option due to its
                      variable, and possibly substantial, overhead.

                    


                    

                    
Stephan   

                    


                    

                    


                    

                    
                      
 From: Justin
                        Uberti <juberti@google.com>

                        Date: Friday,

                        19 July, 2013 06:32 

                        To: Bernard

                        Aboba <bernard_aboba@hotmail.com>

                        Cc: "avtext@ietf.org"
                        <avtext@ietf.org>,

                        "rtcweb@ietf.org"
                        <rtcweb@ietf.org>

                        Subject: Re:

                        [rtcweb] Fwd: New Version Notification for
                        draft-fineberg-avtext-temporal-layer-ext-00.txt

                      

                      


                      

                      

                        

                          
Agree those are the right
                            codecs to design for. Since in each case
                            there are fairly low limits on the number of
                            supported layers (i.e. 3 spatial layers for
                            SVC), I think it should be possible to pack
                            the temporal, spatial, quality layer ids
                            into 16 bits.
                            


                              

                              
On Fri, Jul
                                19, 2013 at 1:56 AM, Bernard Aboba  <bernard_aboba@hotmail.com>
                                wrote:

                                

                                  

                                    
If we can support VP8/9 as well
                                      as H.264/5 SVC

                                    
that would be a start. It seems
                                      doable to me.

                                    

                                      

                                        


                                          On Jul 18, 2013, at 8:34 PM,
                                          "Adam Fineberg" <fineberg@vline.me>

                                          wrote:

                                          

                                        

                                        

                                          

                                            
Bernard,

                                              

                                              Are there other codecs you
                                              are thinking should be
                                              supported?  If it's
                                              generalized I would think
                                              we want to be able to
                                              cover all known scalable
                                              codecs. I'll look into the
                                              H264/SVC fields to see how
                                              to encode them in a
                                              generalized header.

                                              

                                              Regards,

                                              Adam

                                              

                                              On 7/18/13 7:40 PM,
                                              Bernard Aboba wrote:

                                            

                                            

                                              
I think it
                                                may be possible to
                                                generalize this.  For
                                                example, for H.264/SVC
                                                which can support
                                                temporal, spatial and
                                                quality scalability, you
                                                would need the
                                                quality_id and
                                                dependency_id in
                                                addition to the
                                                temporal_id (what you
                                                call the temporal layer
                                                index).    

                                                

                                                

                                                  
 Date: Thu, 18 Jul
                                                  2013 08:45:38 -0700

                                                  From: fineberg@vline.me

                                                  To: 
                                                    bernard_aboba@hotmail.com

                                                  CC: rtcweb@ietf.org; avtext@ietf.org

                                                  Subject: Re: [rtcweb]
                                                  Fwd: New Version
                                                  Notification for
draft-fineberg-avtext-temporal-layer-ext-00.txt

                                                  

                                                  Bernard,

                                                  

                                                  Good question.  I'm
                                                  not familiar enough
                                                  with the parameter
                                                  requirements of all
                                                  other scalable codecs
                                                  to be able to
                                                  generalize.  If you'd
                                                  like to help specify
                                                  them, I'd be fine
                                                  revising the draft to
                                                  generalize.

                                                  

                                                  Regards,

                                                  Adam

                                                  

                                                  
On 7/17/13 8:26
                                                    PM, Bernard Aboba
                                                    wrote:

                                                  

                                                  

                                                    
Since
                                                      the need is not
                                                      codec specific
                                                      (e.g. it arises
                                                      with any codec
                                                      supporting
                                                      temporal, spatial
                                                      and quality
                                                      scalability), why
                                                      

                                                       a VP8-specific
                                                      RTP extension? 

                                                       

                                                      

                                                        
 Date: Wed,
                                                        17 Jul 2013
                                                        17:09:46 -0700

                                                        From: fineberg@vline.me

                                                        To: rtcweb@ietf.org

                                                        Subject:
                                                        [rtcweb] Fwd:
                                                        New Version
                                                        Notification for
draft-fineberg-avtext-temporal-layer-ext-00.txt

                                                        

                                                        Hi,

                                                        

                                                        I'm working on WebRTC services and have
                                                          found that
                                                          while
                                                          developing
                                                          services that
                                                          forward VP8
                                                          video streams
                                                          if we want to
                                                          take advantage
                                                          of the VP8
                                                          temporal
                                                          scaling we
                                                          must get the
                                                          temporal layer
                                                          information
                                                          from the RTP
                                                          header which
                                                          requires us to
                                                          decrypt the
                                                          SRTP packets.
                                                          This is
                                                          undesirable
                                                          both because
                                                          the middle-box
                                                          needs to have
                                                          access to the
                                                          keys as well
                                                          as the because
                                                          of the added
                                                          overhead of
                                                          the
                                                          decrypt/encrypt
                                                          cycle. This
                                                          draft proposes
                                                          an RTP header
                                                          extension that
                                                          will allow us
                                                          to use the VP8
                                                          temporal layer
                                                          information
                                                          included in
                                                          the header
                                                          extension and
                                                          therefore do
                                                          forwarding
                                                          without SRTP
                                                          decryption.
                                                          Comments
                                                          welcome.

                                                        

                                                        Regards,

                                                        Adam Fineberg

                                                        
fineberg at vline.com

                                                          

                                                          --------
                                                          Original
                                                          Message
                                                          --------
                                                          

                                                          
                                                          

                                                          Subject:
                                                          New
                                                          Version
                                                          Notification
                                                          for
                                                          draft-fineberg-avtext-temporal-layer-ext-00.txt
                                                          

                                                          

                                                          Date:
                                                          Tue, 09
                                                          Jul 2013
                                                          10:02:05 -0700
                                                          

                                                          

                                                          From:
                                                          internet-drafts

                                                          at ietf.org
                                                          

                                                          

                                                          To:
                                                          Adam
                                                          Fineberg <fineberg at vline.com>
                                                          

                                                          
                                                          

                                                          

                                                          

                                                          
A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00


Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.


                                                        

                                                        

                                                        _______________________________________________

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

                                                    

                                                  

                                                  

                                                  
-- 
Regards,
Adam

                                                

                                              

                                            

                                            

                                          

                                        

                                      

                                    

                                  

                                  

_______________________________________________

                                  rtcweb mailing list

                                  rtcweb@ietf.org

                                  https://www.ietf.org/mailman/listinfo/rtcweb

                                  

                                

                              

                              

                            

                          

                        

                      

                    

                    

                    

                    
_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

                  

                  

                  
-- 
Regards,
Adam

                

              

             

          

          
-- 
Regards,
Adam

        

      

    

    

    
-- 
Regards,
Adam

  


--------------010308000106040700070801--

From mom040267@gmail.com  Wed Jul 24 00:11:22 2013
Return-Path: 
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 5EAC221F9B0D; Wed, 24 Jul 2013 00:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, 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 KkLGO9PF5Ygq; Wed, 24 Jul 2013 00:11:21 -0700 (PDT)
Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id B19AE21F9011; Wed, 24 Jul 2013 00:11:21 -0700 (PDT)
Received: by mail-pb0-f41.google.com with SMTP id rp16so9471149pbb.28 for ; Wed, 24 Jul 2013 00:11:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ckE9drNK/meu1p7jSl2RuPZEg2xWJoLnM99Co79r52Y=; b=DBExkhiUDBuwucEr6PnZxVhp/ySyDnVWhjFwiXLSY/YfyeuSDDcG9VxsAFDp+SRxZQ BSLNYgVpwvOh11kfVFfdwWRW63cBfmTfoLrDZAnlSsvKtmHy3fFN8EwHGW9fqCIRvn1d JLyyn0lNlX8CR8vcI3LLIpwXAA49ilVzVNniQ+xUrLCWPsGSxaEg77X+g6dO+N79D+A0 TUCI0PhRrnUXbzk38yPHRPF/7owllL6Ls0CyKZUR7QP9/1HEwvtzyfc5il1z8v+TuWvj VQ0nQO9aMo8YGmHvvvS0YbcRozc0e5/qVPsek3r4T6+eNh7TbABc/ir49EB5Vxbi9z2K HiVA==
MIME-Version: 1.0
X-Received: by 10.68.111.129 with SMTP id ii1mr40987113pbb.95.1374649881412; Wed, 24 Jul 2013 00:11:21 -0700 (PDT)
Received: by 10.68.92.132 with HTTP; Wed, 24 Jul 2013 00:11:21 -0700 (PDT)
In-Reply-To: 
References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com>    <51E70106.8060100@goodadvice.pages.de>    <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de>   
Date: Wed, 24 Jul 2013 00:11:21 -0700
Message-ID: 
From: Oleg Moskalenko 
To: Rajmohan Banavi 
Content-Type: multipart/alternative; boundary=047d7b5d9ff7df488e04e23c9d1f
X-Mailman-Approved-At: Wed, 24 Jul 2013 15:19:38 -0700
Cc: behave , "rtcweb@ietf.org" 
Subject: Re: [rtcweb] [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jul 2013 07:11:22 -0000

--047d7b5d9ff7df488e04e23c9d1f
Content-Type: text/plain; charset=ISO-8859-1

Please see my comments in the text:


On Tue, Jul 23, 2013 at 11:54 PM, Rajmohan Banavi
wrote:

>
> Just to make my earlier point clearer - The credentials are generated by
> TURN server and validated by TURN server. None of the other components in
> the chain - web server, web application and the webrtc client, are
> concerned with it (sort of like a blob). So the interoperability is not an
> issue at all irrespective of what implementation approach you take.
>

This is not the case. It is not the TURN server who generates the
credentials. The web server must generate the temporary password, and to be
able to do that the web server must have the shared secret - the same as
TURN server has. How they share the same shared secret I'd leave outside
the proposed specs.



>
> I had some other comments earlier, which are collated below.
>
>    1. What does the web server do with the shared (with TURN server)
>    secret key? This is not clear from the text.
>
> It is rather clear - the web server takes the shared secret and it
generates the temporary password for long-term TURN credentials. The TURN
server can reproduce that generation process and obtain the same temporary
password - because the TURN server knows the same shared secret as the web
server.


>
>    1.
>    2. Sec 4.2 Server - "Note that the REALM value supplied by the server
>    is not meaningful in this context, and can be set to any valid value".
>    Which realm value is being referred here? The REALM attribute value in the
>    401 challenge response sent by the TURN server (in response to initial
>    ALLOCATE request)?
>
>
I do not see those words in the draft text on the Internet:

http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00

is there a newer version somewhere ?


>
>    1.
>    2. The 2 statements seem to be contradictory: sec 1 "However, as a
>    relay service, it imposes a nontrivial cost on the service provider". sec
>    5.1 "The assumption is that TURN services are of low enough value that
>    waiting for the timeout to expire is a valid approach for dealing with
>    possibly-compromised credentials". I am OK with the text, but would prefer
>    if this could be reworded in anyway.
>
>
I'd really like to have an access to the fresh draft,it seems like it was
not posted publicly - I cannot find it.

Thanks
Oleg

--047d7b5d9ff7df488e04e23c9d1f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Please see my comments in the text:


On Tue, Jul 23, 2013 at 11:54 PM=
, Rajmohan Banavi <rajmohanbanavi@gmail.com> wrote:


Just=
 to make my earlier point clearer - The credentials are generated by TURN s=
erver and validated by TURN server. None of the other components in the cha=
in - web server, web application and the webrtc client, are concerned with =
it (sort of like a blob). So the interoperability is not an issue at all ir=
respective of what implementation approach you take.


This is not the case. It is not the =
TURN server who generates the credentials. The web server must generate the=
 temporary password, and to be able to do that the web server must have the=
 shared secret - the same as TURN server has. How they share the same share=
d secret I'd leave outside the proposed specs.



=A0
<=
div dir=3D"ltr">

I had some other comments earlier, which are collated below.


  1. What does the web server do with the sha=
red (with TURN server) secret key? This is not clear from the text.
It is rather clear - the web server tak=
es the shared secret and it generates the temporary password for long-term =
TURN credentials. The TURN server can reproduce that generation process and=
 obtain the same temporary password - because the TURN server knows the sam=
e shared secret as the web server.


=A0
  1. 

  2. Sec 4.2 Server - "Note that the REALM value supplied by the s=
erver is not meaningful in this context, and can be set to any valid value&=
quot;. Which realm value is being referred here? The REALM attribute value =
in the 401 challenge response sent by the TURN server (in response to initi=
al ALLOCATE request)?
    


I do not see those w=
ords in the draft text on the Internet:

http://tools.ietf.org/html/draf=
t-uberti-rtcweb-turn-rest-00


is there a newer version somewhere ?
=A0
=



  1. 

  2. The 2 statements seem to be contradictory: sec 1 "However, as=
 a relay service, it imposes a nontrivial cost on the service provider"=
;. sec 5.1 "The assumption is that TURN services are of low enough val=
ue that waiting for the timeout to expire is a valid approach for dealing w=
ith possibly-compromised credentials". I am OK with the text, but woul=
d prefer if this could be reworded in anyway.
    3. 





I'd really like=
 to have an access to the fresh draft,it seems like it was not posted publi=
cly - I cannot find it.

Thanks
Oleg

--047d7b5d9ff7df488e04e23c9d1f-- From mom040267@gmail.com Wed Jul 24 07:06:54 2013 Return-Path: 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 1E50711E8104; Wed, 24 Jul 2013 07:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 J9DnzXIg-Pap; Wed, 24 Jul 2013 07:06:52 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 932AF11E80CC; Wed, 24 Jul 2013 07:06:52 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so693808pab.25 for ; Wed, 24 Jul 2013 07:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xUzLCbuf1A4hw8HxbtvBxxnd974xTtPiJ5TGpIT4ZtA=; b=ubxJtuA7dMtj2YeJZKqGdmWXe7ApSM5hFIV4oKw3fd6kjlg1ZwVshMDekptTOimSX+ eE67xVwFnde3d9UAy/03D5f+PHfvgLwN+uUP0NthQ0foN1/GEIkDU2oSz155qxMEA+QR k9+gVZmjWsGOqAvTHTCipJviHWiobUrGlAlNwyMXkzTVMH7BevM11d3R+ZxA/NsMX16d wMMnRJAlXYtcKP97D8mDR4r3eEGGJlBr1YbWhjrmcL4kzCAOAjiDtt4rXfRLpgWYxhv8 rq5AWQbE7AYvZDFskhgnXWDrpyIDAzv4d0fXXbP4fS+hTwxShSo3B3MFmXKgDb9aAuTm I3yA== MIME-Version: 1.0 X-Received: by 10.68.99.98 with SMTP id ep2mr41730581pbb.6.1374674787666; Wed, 24 Jul 2013 07:06:27 -0700 (PDT) Received: by 10.68.92.132 with HTTP; Wed, 24 Jul 2013 07:06:27 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> Date: Wed, 24 Jul 2013 07:06:27 -0700 Message-ID: From: Oleg Moskalenko To: Rajmohan Banavi Content-Type: multipart/alternative; boundary=047d7b6d7a6466913a04e2426a0e X-Mailman-Approved-At: Wed, 24 Jul 2013 15:19:38 -0700 Cc: behave , "rtcweb@ietf.org" Subject: Re: [rtcweb] [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:06:54 -0000 --047d7b6d7a6466913a04e2426a0e Content-Type: text/plain; charset=ISO-8859-1 Thank you for the new link. I checked the new version of the draft and I personally see no problem in the text. There is no proprietary software requirements in the draft. It simply defines the logic how the TURN server and web server can organize the temporary password generation, without imposing any proprietary requirements and specs on the software. It is mentioning a possible communication channel between web server and TURN server without defining any specs and as it is written that channel is not required. As it is written, I do not think that it has to be separated into two pieces - it is a single solid logical functionality definition. Thanks Oleg On Wed, Jul 24, 2013 at 1:46 AM, Rajmohan Banavi wrote: > This is the draft (BEHAVE WG) I am referring to - > http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 > > >> This is not the case. It is not the TURN server who generates the >> credentials. The web server must generate the temporary password, and to be >> able to do that the web server must have the shared secret - the same as >> TURN server has. How they share the same shared secret I'd leave outside >> the proposed specs. >> >> OK fine. > > >> It is rather clear - the web server takes the shared secret and it >> generates the temporary password for long-term TURN credentials. The TURN >> server can reproduce that generation process and obtain the same temporary >> password - because the TURN server knows the same shared secret as the web >> server. >> > > OK fine. > > Thanks, > Rajmohan > --047d7b6d7a6466913a04e2426a0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for the new link.

I checked th= e new version of the draft and I personally see no problem in the text. The= re is no proprietary software requirements in the draft. It simply defines = the logic how the TURN server and web server can organize the temporary pas= sword generation, without imposing any proprietary requirements and specs o= n the software. It is mentioning a possible communication channel between w= eb server and TURN server without defining any specs and as it is written t= hat channel is not required. As it is written, I do not think that it has t= o be separated into two pieces - it is a single solid logical functionality= definition.

Thanks
Oleg


On Wed, Jul 24, 2013 at 1:46 AM, Rajmohan Banavi <rajmohanbanavi@gmail.com> wrote:
This is the draft (BEHAVE WG) I am referri= ng to -=A0http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00=


This is not the case. It is not the TURN server who generat= es the credentials. The web server must generate the temporary password, an= d to be able to do that the web server must have the shared secret - the sa= me as TURN server has. How they share the same shared secret I'd leave = outside the proposed specs.

OK fin= e.
=A0
It is rather clear - the web server takes the shared secret and it generat= es the temporary password for long-term TURN credentials. The TURN server c= an reproduce that generation process and obtain the same temporary password= - because the TURN server knows the same shared secret as the web server.<= br>

<= /div>
OK fine.

Th= anks,
Rajmohan

--047d7b6d7a6466913a04e2426a0e-- From yekuiw@qti.qualcomm.com Wed Jul 24 15:32:12 2013 Return-Path: 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 E62A811E8115; Wed, 24 Jul 2013 15:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 4GWUS1+CHGq1; Wed, 24 Jul 2013 15:32:04 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED3521F84E3; Wed, 24 Jul 2013 15:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374705123; x=1406241123; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+UAmFS/l7qp1jhmKa+QEOSqufvCd136bCkp1ZeqpPE8=; b=s356ViqaUbDWbEHMEIDfVTYwDn4H/0yY+o6ie/nmUEKhZwvfBeabCK2K kQnX9YJwUfX47yj7F5fmsBqjKT5zj43mif4tPpzgjoG9VbY1h//elk/mG 0lfq3+/j86aF0d2c2U99V5i6wnxXO0WisQRBPBgH56ueYYbzUUkAfV/Vu c=; X-IronPort-AV: E=Sophos;i="4.89,737,1367996400"; d="scan'208,217";a="48055484" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 24 Jul 2013 15:32:02 -0700 X-IronPort-AV: E=Sophos;i="4.89,737,1367996400"; d="scan'208,217";a="484769105" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Jul 2013 15:32:02 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.108]) by nasanexhc08.na.qualcomm.com ([172.30.39.7]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 15:32:02 -0700 From: "Wang, Ye-Kui" To: Adam Fineberg , Bernard Aboba Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOiJCjclj0bx0Iw0WEq1cynbFWSZl0aUGA Date: Wed, 24 Jul 2013 22:32:01 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384A0A5B@nasanexd02f.na.qualcomm.com> References: , <51EEA709.2020009@vline.me> <51F00A02.3060204@vline.me> In-Reply-To: <51F00A02.3060204@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.132] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0A5Bnasanexd02fnaqu_" MIME-Version: 1.0 Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:32:12 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0A5Bnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the group is to specify something generic, naturally it should be generi= c enough to cover at least all existing standard scalable video codecs if p= ossible. And I personally think that is possible and not difficult at all. = Thus, why limit to only a few scalable video codecs? I could provide some help here too if needed. BR, YK From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Adam Fineberg Sent: Wednesday, July 24, 2013 10:08 AM To: Bernard Aboba Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Bernard, I apologize if I come across as being difficult here but I stil am not seei= ng the benefits. Since the fields are not the same for the codecs, we will= be multiplexing the bits and that seems to me to add complexity rather tha= n add clarity. Also, I can't find an IETF VP9 document for the payload for= mat to reference. If the group thinks generalization is the right approach= I would appreciate some collaboration on getting the right bit definitions= for the other codecs. Regards, Adam On 7/23/13 12:07 PM, Bernard Aboba wrote: I do not think it is necessary to "support all forms of scalability for all= codecs". In fact, I would make that an explicit "non-goal". All that wa= s suggested is to try to create a single extension that supports a few comm= on cases. If it is possible to handle VP8, VP9 and H.264/SVC in a single = extension that would be sufficient. So why not limit it to that? ________________________________ Date: Tue, 23 Jul 2013 08:53:45 -0700 From: fineberg@vline.me To: stewe@stewe.org CC: juberti@google.com; bernard_aboba@hotmail.co= m; avtext@ietf.org; rtcweb@ietf.org Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach. = I'm not sure what we really gain by trying to capture all this in a single = header extension rather than one per that can succinctly explain the fields= without the complexity of multiplexing the bits. Thoughts? Regards, Adam On 7/19/13 3:44 PM, Stephan Wenger wrote: Hi, From: Adam Fineberg > Date: Friday, 19 July, 2013 15:12 To: Stephan Wenger > Cc: Justin Uberti >, Bernard = Aboba >, "avtex= t@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at= all familiar with H.265. I'll review the reference and see what I can fig= ure. StW: Good luck :-) It seems though to me that you are suggesting that except in the simple cas= e, that the data for H.265 would not be well suited to a header extension, = am I understanding you correctly? There is no reason the middlebox couldn'= t get out of band signaling of the VPS as you mention but that would not be= within the scope of this header extension. StW: well, if you would copy the layer_id into your header extension (just = as you need to do for the simple case), a really smart middle box could use= this information just as a decoder uses it, assuming that it intercepted t= he VPS in the first place. Insofar, I wouldn't rule out the second option = on technical grounds. Whether any of the actual products would bother to d= o that, ever, is another question. I think the case ought to be documented= , though. I can help drafting text. While we are at it: doing this right could mean that you need multiple spec= s. First, a generic header extension mechanism dedicated to side informati= on required for pruning of RTP packet streams-ideally not only for scalable= video, although that is the main customer today. And second, for each "pa= yload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 = (including scalable and 3D extensions, which are not yet finalized), VP8, a= nd VP9 (I know little about the latter), plus Daala, and whatnot) a mapping= of the bits available in the generic header extension to the bits in the p= ayload itself (NAL header and VPS in case of H.265, NALU header in SVC, and= the fields you mention for VP8). Stephan Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling-as the encrypted in-band VPS would not be useful under the assump= tion that the middle box does not have the key to the media-which is the mo= tivation of the draft in the first place). I personally don't mind at all = the second mechanism, as I'm a big fan of out-of-band parameter set transmi= ssion and any middle box must be in the signaling path anyway to meaningful= ly manipulate RTP. I do not like the first option due to its variable, and= possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.tx= t Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for= VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ avtext mailing list avtext@ietf.orghttps://www.ietf.org/mailman/listinf= o/avtext -- Regards, Adam -- Regards, Adam -- Regards, Adam --_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0A5Bnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If the group is to specif= y something generic, naturally it should be generic enough to cover at leas= t all existing standard scalable video codecs if possible. And I personally think that is possible and not difficult at all. Thus, wh= y limit to only a few scalable video codecs?

 <= /p>

I could provide some help= here too if needed.

 <= /p>

BR, YK<= /p>

 <= /p>

From:= avtext-bounces@ietf= .org [mailto:avtext-bounces@ietf.org] On Behalf Of Adam Fineberg
Sent: Wednesday, July 24, 2013 10:08 AM
To: Bernard Aboba
Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Bernard,

I apologize if I come across as being difficult here but I stil am not seei= ng the benefits.  Since the fields are not the same for the codecs, we= will be multiplexing the bits and that seems to me to add complexity rathe= r than add clarity.  Also, I can't find an IETF VP9 document for the payload format to reference.  If the gro= up thinks generalization is the right approach I would appreciate some coll= aboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:=

I do not think it is = necessary to "support all forms of scalability for all codecs".&n= bsp;  In fact, I would make that an explicit "non-goal".&nbs= p; All that was suggested is to try to create a single extension that suppo= rts a few common cases.   If it is possible to handle VP8, VP9 and H= .264/SVC in a single extension that would be sufficient.  So why not l= imit it to that?

Date: Tue, 23 Jul 201= 3 08:53:45 -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ie= tf.org; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach.  I'm not sure what we really gain by = trying to capture all this in a single header extension rather than one per= that can succinctly explain the fields without the complexity of multiplex= ing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:=

Hi,=

 

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stew= e.org>
Cc: Justin Uberti <juberti@= google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <a= vtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm n= ot at all familiar with H.265.  I'll review the reference and see what= I can figure. 

 

StW: Good luck :-)  

 

It seems though to me that you are sugg= esting that except in the simple case, that the data for H.265 would not be= well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band= signaling of the VPS as you mention but that would not be within the scope= of this header extension.

 

StW: well, if you would copy the layer_id int= o your header extension (just as you need to do for the simple case), a rea= lly smart middle box could use this information just as a decoder uses it, assuming that it intercepted the VPS in the f= irst place.  Insofar, I wouldn't rule out the second option on technic= al grounds.  Whether any of the actual products would bother to do tha= t, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.

While we are at it: doing this right could me= an that you need multiple specs.  First, a generic header extension me= chanism dedicated to side information required for pruning of RTP packet streams—ideally not only for scalable video, although tha= t is the main customer today.  And second, for each "payload"= ; (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (incl= uding scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a = mapping of the bits available in the generic header extension to the bits i= n the payload itself (NAL header and VPS in case of H.265, NALU header in S= VC, and the fields you mention for VP8).

 

Stephan<= o:p>



Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrot= e:

Hi,

I also believe that 16 bits should be e= nough.  For H.264 and VP8 that has already been demonstrated.  Fo= r H.265, some initial thoughts below.  Apologies for the word-count.

 

The scalable version of H265 (called SH= VC) is currently under development.  The current working draft can be = found here: http://phenix.i= nt-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

 

That said, the ordering by the encoder = is just a recommendation, and there may well be cases where different pruni= ng strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2= D scalable tools only, the other including view_id for multi view coding. &= nbsp;By looking at the six bit field alone, a middle box will not be able t= o meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In= order to meaningfully deal with that scenario, there would be two options:= one to represent the dimension_id[][] (and associated control info) in the= header extension, or require the middle box to have access to the VPS and be able to interpret its content.  = The further could take considerably more than 16 bits and we would be talki= ng about a variable length data structure.  The latter requires the mi= ddle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS wo= uld not be useful under the assumption that the middle box does not have th= e key to the media—which is the motivation of the draft in the first = place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmissi= on and any middle box must be in the signaling path anyway to meaningfully = manipulate RTP.  I do not like the first option due to its variable, a= nd possibly substantial, overhead.

 

Stephan   <= /p>

 

 

From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <b= ernard_aboba@hotmail.com>
Cc: "avtext@ietf.org&quo= t; <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-finebe= rg-avtext-temporal-layer-ext-00.txt

 

Agree those are the right codecs to des= ign for. Since in each case there are fairly low limits on the number of su= pported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids int= o 16 bits.

&nb= sp;

On Fri, Jul 19, 2013 at 1:56 AM, Bernar= d Aboba <= bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.26= 4/5 SVC

that would be a start. It seems doable = to me.


On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:

I think = it may be possible to generalize this.  For example, for H.264/SVC whi= ch can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what= you call the temporal layer index).   

Date: Th= u, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline= .me
To: bernard_= aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote= :

Since the need is not codec specific (e= .g. it arises with any codec supporting temporal, spatial and quality scala= bility), why
 a VP8-specific RTP extension?
 

Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline= .me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to= have access to the keys as well as the because of the added overhead of th= e decrypt/encrypt cycle. This draft proposes an RTP header extension that w= ill allow us to use the VP8 temporal layer information included in the header extension and therefore do forwar= ding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg

fineberg at vline.com

-------- Original Message --------

Subjec= t:

New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Date:<= o:p>

Tue, 09 Jul 2013 10:02:05 -0700

From:<= o:p>

internet-drafts at ietf.org

To:

Adam Fineberg <fineberg at vline.com><= /p> 




A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt<=
o:p>
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:         draft-fineberg-av=
text-temporal-layer-ext
Revision:         00

Title:            A =
Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer =
Information


Creation date:    2013-07-08


Group:            In=
dividual Submission


Number of pages: 6


URL:           =
  http://www.ietf.org/internet-=
drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt


Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-=
temporal-layer-ext


Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext=
-00


 


 


Abstract:


   This document defines a mechanism by which packets of Rea=
l-Time


   Tranport Protocol (RTP) video streams encoded with the VP=
8 codec can


   indicate, in an RTP header extension, the temporal layer =
information


   about the frame encoded in the RTP packet.  This inf=
ormation can be


   used in a middlebox performing bandwidth management of st=
reams


   without requiring it to decrypt the streams.


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

 

-- 
Regards,
Adam

 


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

 



_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf=
.org/mailman/listinfo/avtext

 

-- 
Regards,
Adam

 

-- 
Regards,
Adam



-- 
Regards,
Adam
--_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0A5Bnasanexd02fnaqu_-- From fineberg@vline.me Wed Jul 24 15:55:06 2013 Return-Path: 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 7D80311E814D for ; Wed, 24 Jul 2013 15:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ckiSp1rrM+MU for ; Wed, 24 Jul 2013 15:54:59 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id CE2EC11E8123 for ; Wed, 24 Jul 2013 15:54:45 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so14603876obb.15 for ; Wed, 24 Jul 2013 15:54:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=VS+ZwlJursITT/5OjN/vg5RNwOlSruohaYVgzvz2juE=; b=dKKXPcxtdErqesei0zGewiC0xipQVJuumpU85lD+zIgH/5We7M7IwMn7EvH+apB+K7 qvu/wazs/F5yJxM5BeTFcYdEn7+unSaYotPEVRiyzmawoGnqP+uP5BALCRRy+MfuqWQK lWNyyAAphLPLgm9XJ19u/k55Rc+cQKT9CnWXfTPbBbZ9zog1CWp14JUfVc2ZUstmsXDx uiXmVfXcO/uv2w809F87vsninmnwNSrNUIiA45eG0FzkUl5iBpNAFPX4lq1ZE0n05M9Z DL5inuGfZtJi9MlR4kgfNQDZP6fCwsHjw2Y5v10a6Ioq0ze021GGfpDaXbxx2km0b4p4 6avg== X-Received: by 10.50.164.167 with SMTP id yr7mr711148igb.22.1374706483543; Wed, 24 Jul 2013 15:54:43 -0700 (PDT) Received: from Adams-MacBook-Pro.local ([38.102.150.73]) by mx.google.com with ESMTPSA id z15sm8747igp.0.2013.07.24.15.54.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 15:54:42 -0700 (PDT) Message-ID: <51F05B32.5080401@vline.me> Date: Wed, 24 Jul 2013 15:54:42 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Wang, Ye-Kui" References: , <51EEA709.2020009@vline.me> <51F00A02.3060204@vline.me> <8BA7D4CEACFFE04BA2D902BF11719A83384A0A5B@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384A0A5B@nasanexd02f.na.qualcomm.com> Content-Type: multipart/alternative; boundary="------------060504090401040709000905" X-Gm-Message-State: ALoCoQmHDlKjgoOPrRNJwdR3vkN+ulibU+HINZ7LEWcNDpcDAhD0fLToYH0vpW+LaSE4yFVOJV1U Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:55:06 -0000 This is a multi-part message in MIME format. --------------060504090401040709000905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit YK, I would appreciate your collaboration. Which codecs are you referring to when you say "all existing standard scalable video codecs"? Regards, Adam On 7/24/13 3:32 PM, Wang, Ye-Kui wrote: > > If the group is to specify something generic, naturally it should be > generic enough to cover at least all existing standard scalable video > codecs if possible. And I personally think that is possible and not > difficult at all. Thus, why limit to only a few scalable video codecs? > > I could provide some help here too if needed. > > BR, YK > > *From:*avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] *On > Behalf Of *Adam Fineberg > *Sent:* Wednesday, July 24, 2013 10:08 AM > *To:* Bernard Aboba > *Cc:* avtext@ietf.org; rtcweb@ietf.org; Justin Uberti > *Subject:* Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Bernard, > > I apologize if I come across as being difficult here but I stil am not > seeing the benefits. Since the fields are not the same for the > codecs, we will be multiplexing the bits and that seems to me to add > complexity rather than add clarity. Also, I can't find an IETF VP9 > document for the payload format to reference. If the group thinks > generalization is the right approach I would appreciate some > collaboration on getting the right bit definitions for the other codecs. > > Regards, > Adam > > On 7/23/13 12:07 PM, Bernard Aboba wrote: > > I do not think it is necessary to "support all forms of > scalability for all codecs". In fact, I would make that an > explicit "non-goal". All that was suggested is to try to create a > single extension that supports a few common cases. If it is > possible to handle VP8, VP9 and H.264/SVC in a single extension > that would be sufficient. So why not limit it to that? > > ------------------------------------------------------------------------ > > Date: Tue, 23 Jul 2013 08:53:45 -0700 > From: fineberg@vline.me > To: stewe@stewe.org > CC: juberti@google.com ; > bernard_aboba@hotmail.com ; > avtext@ietf.org ; rtcweb@ietf.org > > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > I've been thinking about this and given the ease at which RFC5285 > allows for the specification of a header extension and the > complexity introduced by trying to generalize the header extension > to support all forms of scalability for all codecs that the > generalization might not be the best approach. I'm not sure what > we really gain by trying to capture all this in a single header > extension rather than one per that can succinctly explain the > fields without the complexity of multiplexing the bits. > > Thoughts? > > Regards, > Adam > > On 7/19/13 3:44 PM, Stephan Wenger wrote: > > Hi, > > *From: *Adam Fineberg > > *Date: *Friday, 19 July, 2013 15:12 > *To: *Stephan Wenger > > *Cc: *Justin Uberti >, Bernard Aboba > >, "avtext@ietf.org > " >, "rtcweb@ietf.org > " > > *Subject: *Re: [avtext] [rtcweb] Fwd: New Version Notification > for draft-fineberg-avtext-temporal-layer-ext-00.txt > > Stephan, > > Thanks for the info and the reference. I'm not sure I follow > as I'm not at all familiar with H.265. I'll review the > reference and see what I can figure. > > StW: Good luck :-) > > It seems though to me that you are suggesting that except in > the simple case, that the data for H.265 would not be well > suited to a header extension, am I understanding you > correctly? There is no reason the middlebox couldn't get out > of band signaling of the VPS as you mention but that would not > be within the scope of this header extension. > > StW: well, if you would copy the layer_id into your header > extension (just as you need to do for the simple case), a > really smart middle box could use this information just as a > decoder uses it, assuming that it intercepted the VPS in the > first place. Insofar, I wouldn't rule out the second option > on technical grounds. Whether any of the actual products > would bother to do that, ever, is another question. I think > the case ought to be documented, though. I can help drafting > text. > > While we are at it: doing this right could mean that you need > multiple specs. First, a generic header extension mechanism > dedicated to side information required for pruning of RTP > packet streams---ideally not only for scalable video, although > that is the main customer today. And second, for each > "payload" (at present we are talking about H.264/SVC, H.265v1 > (HEVC), H.265v2 (including scalable and 3D extensions, which > are not yet finalized), VP8, and VP9 (I know little about the > latter), plus Daala, and whatnot) a mapping of the bits > available in the generic header extension to the bits in the > payload itself (NAL header and VPS in case of H.265, NALU > header in SVC, and the fields you mention for VP8). > > Stephan > > > > Any insights are appreciated. > > Regards, > Adam > > On 7/19/13 8:33 AM, Stephan Wenger wrote: > > Hi, > > I also believe that 16 bits should be enough. For H.264 > and VP8 that has already been demonstrated. For H.265, > some initial thoughts below. Apologies for the word-count. > > The scalable version of H265 (called SHVC) is currently > under development. The current working draft can be found > here: > http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. > Therein, the options for defining layering structures are > considerably more complex. To start, we have 3 bits for > the temporal ID in the NAL unit header of the H.265 > version 1 (HEVC) base specification (temporal scalability > is already nicely supported in version 1). Just like in > SVC. In the scalable extension, the NAL unit header > contains a six bit field that points into a data structure > known as "Video Parameter Set" (VPS). Inside the VPS, > those six bits are mapped to to a position in a directed > graph (specified through "dimension_id[][]"), which tells > you about the reference relationship of the layer in > question and its parent layer. One can recursively follow > the graph to determine what used to be called > dependency_id, quality_id, view_id, and whatnot. The six > bit pointer field can (or: is to be when possible) > organized by the encoder such that it is prudent for a > middle box to throw away NAL units (belonging to layers) > with higher values of the six bit field first, before > throwing away NAL units with lower values. Relying on > this feature, 3+6 bits == 9 bits should be fine for the > header extension. > > That said, the ordering by the encoder is just a > recommendation, and there may well be cases where > different pruning strategies may be advisable. For > example, a layering structure could be constructed that > expands into two branches, one using 2D scalable tools > only, the other including view_id for multi view coding. > By looking at the six bit field alone, a middle box will > not be able to meaningfully remove NAL units belonging to > one of the branches completely while pruning the other > branch. In order to meaningfully deal with that scenario, > there would be two options: one to represent the > dimension_id[][] (and associated control info) in the > header extension, or require the middle box to have access > to the VPS and be able to interpret its content. The > further could take considerably more than 16 bits and we > would be talking about a variable length data structure. > The latter requires the middle box to have state and a > mechanism to intercept the VPS (through signaling---as the > encrypted in-band VPS would not be useful under the > assumption that the middle box does not have the key to > the media---which is the motivation of the draft in the > first place). I personally don't mind at all the second > mechanism, as I'm a big fan of out-of-band parameter set > transmission and any middle box must be in the signaling > path anyway to meaningfully manipulate RTP. I do not like > the first option due to its variable, and possibly > substantial, overhead. > > Stephan > > *From: *Justin Uberti > > *Date: *Friday, 19 July, 2013 06:32 > *To: *Bernard Aboba > > *Cc: *"avtext@ietf.org " > >, > "rtcweb@ietf.org " > > > *Subject: *Re: [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Agree those are the right codecs to design for. Since in > each case there are fairly low limits on the number of > supported layers (i.e. 3 spatial layers for SVC), I think > it should be possible to pack the temporal, spatial, > quality layer ids into 16 bits. > > On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > > wrote: > > If we can support VP8/9 as well as H.264/5 SVC > > that would be a start. It seems doable to me. > > > On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > > wrote: > > Bernard, > > Are there other codecs you are thinking should be > supported? If it's generalized I would think we want > to be able to cover all known scalable codecs. I'll > look into the H264/SVC fields to see how to encode > them in a generalized header. > > Regards, > Adam > > On 7/18/13 7:40 PM, Bernard Aboba wrote: > > I think it may be possible to generalize this. For > example, for H.264/SVC which can support temporal, > spatial and quality scalability, you would need > the quality_id and dependency_id in addition to > the temporal_id (what you call the temporal layer > index). > > ------------------------------------------------------------------------ > > Date: Thu, 18 Jul 2013 08:45:38 -0700 > From: fineberg@vline.me > To: bernard_aboba@hotmail.com > > CC: rtcweb@ietf.org ; > avtext@ietf.org > Subject: Re: [rtcweb] Fwd: New Version > Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Bernard, > > Good question. I'm not familiar enough with the > parameter requirements of all other scalable > codecs to be able to generalize. If you'd like to > help specify them, I'd be fine revising the draft > to generalize. > > Regards, > Adam > > On 7/17/13 8:26 PM, Bernard Aboba wrote: > > Since the need is not codec specific (e.g. it > arises with any codec supporting temporal, > spatial and quality scalability), why > a VP8-specific RTP extension? > > ------------------------------------------------------------------------ > > Date: Wed, 17 Jul 2013 17:09:46 -0700 > From: fineberg@vline.me > To: rtcweb@ietf.org > Subject: [rtcweb] Fwd: New Version > Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found > that while developing services that forward > VP8 video streams if we want to take advantage > of the VP8 temporal scaling we must get the > temporal layer information from the RTP header > which requires us to decrypt the SRTP packets. > This is undesirable both because the > middle-box needs to have access to the keys as > well as the because of the added overhead of > the decrypt/encrypt cycle. This draft proposes > an RTP header extension that will allow us to > use the VP8 temporal layer information > included in the header extension and therefore > do forwarding without SRTP decryption. > Comments welcome. > > Regards, > Adam Fineberg > > fineberg at vline.com > > > -------- Original Message -------- > > *Subject:* > > > > New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > *Date:* > > > > Tue, 09 Jul 2013 10:02:05 -0700 > > *From:* > > > > internet-drafts at ietf.org > > > *To:* > > > > Adam Fineberg > > > > > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > > has been successfully submitted by Adam Fineberg and posted to the > > IETF repository. > > > > Filename: draft-fineberg-avtext-temporal-layer-ext > > Revision: 00 > > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > > Creation date: 2013-07-08 > > Group: Individual Submission > > Number of pages: 6 > > URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > > Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > > Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > > > > Abstract: > > This document defines a mechanism by which packets of Real-Time > > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > > indicate, in an RTP header extension, the temporal layer information > > about the frame encoded in the RTP packet. This information can be > > used in a middlebox performing bandwidth management of streams > > without requiring it to decrypt the streams. > > > _______________________________________________ rtcweb > mailing list rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > -- > > Regards, > > Adam > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext > > -- > > Regards, > > Adam > > -- > > Regards, > > Adam > > > > -- > Regards, > Adam -- Regards, Adam --------------060504090401040709000905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit YK,

I would appreciate your collaboration.  Which codecs are you referring to when you say "all existing standard scalable video codecs"?

Regards,
Adam

On 7/24/13 3:32 PM, Wang, Ye-Kui wrote:

If the group is to specify something generic, naturally it should be generic enough to cover at least all existing standard scalable video codecs if possible. And I personally think that is possible and not difficult at all. Thus, why limit to only a few scalable video codecs?

 

I could provide some help here too if needed.

 

BR, YK

 

From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Adam Fineberg
Sent: Wednesday, July 24, 2013 10:08 AM
To: Bernard Aboba
Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Bernard,

I apologize if I come across as being difficult here but I stil am not seeing the benefits.  Since the fields are not the same for the codecs, we will be multiplexing the bits and that seems to me to add complexity rather than add clarity.  Also, I can't find an IETF VP9 document for the payload format to reference.  If the group thinks generalization is the right approach I would appreciate some collaboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:

I do not think it is necessary to "support all forms of scalability for all codecs".   In fact, I would make that an explicit "non-goal".  All that was suggested is to try to create a single extension that supports a few common cases.   If it is possible to handle VP8, VP9 and H.264/SVC in a single extension that would be sufficient.  So why not limit it to that?

Date: Tue, 23 Jul 2013 08:53:45 -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ietf.org; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows for the specification of a header extension and the complexity introduced by trying to generalize the header extension to support all forms of scalability for all codecs that the generalization might not be the best approach.  I'm not sure what we really gain by trying to capture all this in a single header extension rather than one per that can succinctly explain the fields without the complexity of multiplexing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:

Hi,

 

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm not at all familiar with H.265.  I'll review the reference and see what I can figure. 

 

StW: Good luck :-)  

 

It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

 

StW: well, if you would copy the layer_id into your header extension (just as you need to do for the simple case), a really smart middle box could use this information just as a decoder uses it, assuming that it intercepted the VPS in the first place.  Insofar, I wouldn't rule out the second option on technical grounds.  Whether any of the actual products would bother to do that, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.

While we are at it: doing this right could mean that you need multiple specs.  First, a generic header extension mechanism dedicated to side information required for pruning of RTP packet streams—ideally not only for scalable video, although that is the main customer today.  And second, for each "payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the bits available in the generic header extension to the bits in the payload itself (NAL header and VPS in case of H.265, NALU header in SVC, and the fields you mention for VP8).

 

Stephan



Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:

Hi,

I also believe that 16 bits should be enough.  For H.264 and VP8 that has already been demonstrated.  For H.265, some initial thoughts below.  Apologies for the word-count.

 

The scalable version of H265 (called SHVC) is currently under development.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerably more complex.  To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS).  Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer.  One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

 

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content.  The further could take considerably more than 16 bits and we would be talking about a variable length data structure.  The latter requires the middle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the media—which is the motivation of the draft in the first place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP.  I do not like the first option due to its variable, and possibly substantial, overhead.

 

Stephan   

 

 

From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.

 

On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.264/5 SVC

that would be a start. It seems doable to me.


On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:

I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:

Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 

Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg

fineberg at vline.com

-------- Original Message --------

Subject:

New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Date:

Tue, 09 Jul 2013 10:02:05 -0700

From:

internet-drafts at ietf.org

To:

Adam Fineberg <fineberg at vline.com>

 




A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:         draft-fineberg-avtext-temporal-layer-ext
Revision:         00
Title:            A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:    2013-07-08
Group:            Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00
 
 
Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.


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

 

-- 
Regards,
Adam

 


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

 



_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext

 

-- 
Regards,
Adam

 

-- 
Regards,
Adam



-- 
Regards,
Adam

-- 
Regards,
Adam
--------------060504090401040709000905-- From yekuiw@qti.qualcomm.com Thu Jul 25 00:29:00 2013 Return-Path: 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 4144721F99A2; Thu, 25 Jul 2013 00:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 7eHQ7K2qUssw; Thu, 25 Jul 2013 00:28:47 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5A21F99AB; Thu, 25 Jul 2013 00:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374737324; x=1406273324; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EStTDljTOU1upMqJbbA9iFcRFXp6j330ZJ0LXoHuUZw=; b=ksDPQTwA33PTkWG/DzevUJ60Sx/7YILIdsn7A9eokZyrC2487adbkruG dy57T2UXmX82oL8vKd4AvxNJycft7sjFBWcaNYazWY5d6m+pCfvTkXord CzgJf7cC4G2UgRTznjqG+8ir03Zf/jUNQ48R5A/gr0edwEJTSq68sANp4 4=; X-IronPort-AV: E=Sophos;i="4.89,741,1367996400"; d="scan'208,217";a="48084619" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 25 Jul 2013 00:28:42 -0700 Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Jul 2013 00:28:41 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 25 Jul 2013 00:28:41 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.108]) by nasanexhc05.na.qualcomm.com ([172.30.48.2]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 00:28:41 -0700 From: "Wang, Ye-Kui" To: Adam Fineberg Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOiMDQ739D5cVyN02oHm4OkyMkjZl0/z2g Date: Thu, 25 Jul 2013 07:28:40 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384A0F8F@nasanexd02f.na.qualcomm.com> References: , <51EEA709.2020009@vline.me> <51F00A02.3060204@vline.me> <8BA7D4CEACFFE04BA2D902BF11719A83384A0A5B@nasanexd02f.na.qualcomm.com> <51F05B32.5080401@vline.me> In-Reply-To: <51F05B32.5080401@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.132] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0F8Fnasanexd02fnaqu_" MIME-Version: 1.0 Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:29:00 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0F8Fnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adam, I meant the scalable codecs mentioned so far by everyone, including H.265/H= EVC and its extensions, and H.264/AVC and its extensions. BR, YK From: Adam Fineberg [mailto:fineberg@vline.me] Sent: Wednesday, July 24, 2013 3:55 PM To: Wang, Ye-Kui Cc: Bernard Aboba; avtext@ietf.org; rtcweb@ietf.org; Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt YK, I would appreciate your collaboration. Which codecs are you referring to w= hen you say "all existing standard scalable video codecs"? Regards, Adam On 7/24/13 3:32 PM, Wang, Ye-Kui wrote: If the group is to specify something generic, naturally it should be generi= c enough to cover at least all existing standard scalable video codecs if p= ossible. And I personally think that is possible and not difficult at all. = Thus, why limit to only a few scalable video codecs? I could provide some help here too if needed. BR, YK From: avtext-bounces@ietf.org [mailto:avtex= t-bounces@ietf.org] On Behalf Of Adam Fineberg Sent: Wednesday, July 24, 2013 10:08 AM To: Bernard Aboba Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Bernard, I apologize if I come across as being difficult here but I stil am not seei= ng the benefits. Since the fields are not the same for the codecs, we will= be multiplexing the bits and that seems to me to add complexity rather tha= n add clarity. Also, I can't find an IETF VP9 document for the payload for= mat to reference. If the group thinks generalization is the right approach= I would appreciate some collaboration on getting the right bit definitions= for the other codecs. Regards, Adam On 7/23/13 12:07 PM, Bernard Aboba wrote: I do not think it is necessary to "support all forms of scalability for all= codecs". In fact, I would make that an explicit "non-goal". All that wa= s suggested is to try to create a single extension that supports a few comm= on cases. If it is possible to handle VP8, VP9 and H.264/SVC in a single = extension that would be sufficient. So why not limit it to that? ________________________________ Date: Tue, 23 Jul 2013 08:53:45 -0700 From: fineberg@vline.me To: stewe@stewe.org CC: juberti@google.com; bernard_aboba@hotmail.co= m; avtext@ietf.org; rtcweb@ietf.org Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach. = I'm not sure what we really gain by trying to capture all this in a single = header extension rather than one per that can succinctly explain the fields= without the complexity of multiplexing the bits. Thoughts? Regards, Adam On 7/19/13 3:44 PM, Stephan Wenger wrote: Hi, From: Adam Fineberg > Date: Friday, 19 July, 2013 15:12 To: Stephan Wenger > Cc: Justin Uberti >, Bernard = Aboba >, "avtex= t@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at= all familiar with H.265. I'll review the reference and see what I can fig= ure. StW: Good luck :-) It seems though to me that you are suggesting that except in the simple cas= e, that the data for H.265 would not be well suited to a header extension, = am I understanding you correctly? There is no reason the middlebox couldn'= t get out of band signaling of the VPS as you mention but that would not be= within the scope of this header extension. StW: well, if you would copy the layer_id into your header extension (just = as you need to do for the simple case), a really smart middle box could use= this information just as a decoder uses it, assuming that it intercepted t= he VPS in the first place. Insofar, I wouldn't rule out the second option = on technical grounds. Whether any of the actual products would bother to d= o that, ever, is another question. I think the case ought to be documented= , though. I can help drafting text. While we are at it: doing this right could mean that you need multiple spec= s. First, a generic header extension mechanism dedicated to side informati= on required for pruning of RTP packet streams-ideally not only for scalable= video, although that is the main customer today. And second, for each "pa= yload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 = (including scalable and 3D extensions, which are not yet finalized), VP8, a= nd VP9 (I know little about the latter), plus Daala, and whatnot) a mapping= of the bits available in the generic header extension to the bits in the p= ayload itself (NAL header and VPS in case of H.265, NALU header in SVC, and= the fields you mention for VP8). Stephan Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling-as the encrypted in-band VPS would not be useful under the assump= tion that the middle box does not have the key to the media-which is the mo= tivation of the draft in the first place). I personally don't mind at all = the second mechanism, as I'm a big fan of out-of-band parameter set transmi= ssion and any middle box must be in the signaling path anyway to meaningful= ly manipulate RTP. I do not like the first option due to its variable, and= possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.tx= t Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for= VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ avtext mailing list avtext@ietf.orghttps://www.ietf.org/mailman/listinf= o/avtext -- Regards, Adam -- Regards, Adam -- Regards, Adam -- Regards, Adam --_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0F8Fnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adam,

 <= /p>

I meant the scalable code= cs mentioned so far by everyone, including H.265/HEVC and its extensions, a= nd H.264/AVC and its extensions.

 <= /p>

BR, YK<= /p>

 <= /p>

From:= Adam Fineberg [mail= to:fineberg@vline.me]
Sent: Wednesday, July 24, 2013 3:55 PM
To: Wang, Ye-Kui
Cc: Bernard Aboba; avtext@ietf.org; rtcweb@ietf.org; Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

YK,

I would appreciate your collaboration.  Which codecs are you referring= to when you say "all existing standard scalable video codecs"?

Regards,
Adam

On 7/24/13 3:32 PM, Wang, Ye-Kui wrote:

If the group is to specif= y something generic, naturally it should be generic enough to cover at leas= t all existing standard scalable video codecs if possible. And I personally think that is possible and not difficult at all. Thus, wh= y limit to only a few scalable video codecs?

 <= /p>

I could provide some help= here too if needed.

 <= /p>

BR, YK<= /p>

 <= /p>

From:= avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Adam Fineberg
Sent: Wednesday, July 24, 2013 10:08 AM
To: Bernard Aboba
Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Bernard,

I apologize if I come across as being difficult here but I stil am not seei= ng the benefits.  Since the fields are not the same for the codecs, we= will be multiplexing the bits and that seems to me to add complexity rathe= r than add clarity.  Also, I can't find an IETF VP9 document for the payload format to reference.  If the gro= up thinks generalization is the right approach I would appreciate some coll= aboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:=

I do not think it is = necessary to "support all forms of scalability for all codecs".&n= bsp;  In fact, I would make that an explicit "non-goal".&nbs= p; All that was suggested is to try to create a single extension that suppo= rts a few common cases.   If it is possible to handle VP8, VP9 and H= .264/SVC in a single extension that would be sufficient.  So why not l= imit it to that?

Date: Tue, 23 Jul 201= 3 08:53:45 -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ie= tf.org; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach.  I'm not sure what we really gain by = trying to capture all this in a single header extension rather than one per= that can succinctly explain the fields without the complexity of multiplex= ing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:=

Hi,

 

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stew= e.org>
Cc: Justin Uberti <juberti@= google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <a= vtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm n= ot at all familiar with H.265.  I'll review the reference and see what= I can figure. 

 

StW: Good luck :-)  

 

It seems though to me that you are sugg= esting that except in the simple case, that the data for H.265 would not be= well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band= signaling of the VPS as you mention but that would not be within the scope= of this header extension.

 

StW: well, if you would copy the layer_id int= o your header extension (just as you need to do for the simple case), a rea= lly smart middle box could use this information just as a decoder uses it, assuming that it intercepted the VPS in the f= irst place.  Insofar, I wouldn't rule out the second option on technic= al grounds.  Whether any of the actual products would bother to do tha= t, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.

While we are at it: doing this right could me= an that you need multiple specs.  First, a generic header extension me= chanism dedicated to side information required for pruning of RTP packet streams—ideally not only for scalable video, although tha= t is the main customer today.  And second, for each "payload"= ; (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (incl= uding scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a = mapping of the bits available in the generic header extension to the bits i= n the payload itself (NAL header and VPS in case of H.265, NALU header in S= VC, and the fields you mention for VP8).

 

Stephan



Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrot= e:

Hi,

I also believe that 16 bits should be e= nough.  For H.264 and VP8 that has already been demonstrated.  Fo= r H.265, some initial thoughts below.  Apologies for the word-count.

 

The scalable version of H265 (called SH= VC) is currently under development.  The current working draft can be = found here: http://phenix.i= nt-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

 

That said, the ordering by the encoder = is just a recommendation, and there may well be cases where different pruni= ng strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2= D scalable tools only, the other including view_id for multi view coding. &= nbsp;By looking at the six bit field alone, a middle box will not be able t= o meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In= order to meaningfully deal with that scenario, there would be two options:= one to represent the dimension_id[][] (and associated control info) in the= header extension, or require the middle box to have access to the VPS and be able to interpret its content.  = The further could take considerably more than 16 bits and we would be talki= ng about a variable length data structure.  The latter requires the mi= ddle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS wo= uld not be useful under the assumption that the middle box does not have th= e key to the media—which is the motivation of the draft in the first = place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmissi= on and any middle box must be in the signaling path anyway to meaningfully = manipulate RTP.  I do not like the first option due to its variable, a= nd possibly substantial, overhead.

 

Stephan   <= /p>

 

 

From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <b= ernard_aboba@hotmail.com>
Cc: "avtext@ietf.org&quo= t; <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-finebe= rg-avtext-temporal-layer-ext-00.txt

 

Agree those are the right codecs to des= ign for. Since in each case there are fairly low limits on the number of su= pported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids int= o 16 bits.

 

On Fri, Jul 19, 2013 at 1:56 AM, Bernar= d Aboba <= bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.26= 4/5 SVC

that would be a start. It seems doable = to me.


On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:

I think = it may be possible to generalize this.  For example, for H.264/SVC whi= ch can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what= you call the temporal layer index).   

Date: Th= u, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline= .me
To: bernard_= aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote= :

Since the need is not codec specific (e= .g. it arises with any codec supporting temporal, spatial and quality scala= bility), why
 a VP8-specific RTP extension?
 

Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline= .me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to= have access to the keys as well as the because of the added overhead of th= e decrypt/encrypt cycle. This draft proposes an RTP header extension that w= ill allow us to use the VP8 temporal layer information included in the header extension and therefore do forwar= ding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg

fineberg at vline.com

-------- Original Message --------

Subjec= t:

New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Date:<= /b>

Tue, 09 Jul 2013 10:02:05 -0700

From:<= /b>

internet-drafts at ietf.org

To:

Adam Fineberg <fineberg at vline.com><= /p> 





A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt<=
o:p>
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:         draft-finebe=
rg-avtext-temporal-layer-ext
Revision:         00
Title:          &nbs=
p; A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal L=
ayer Information
Creation date:    2013-07-08
Group:          &nbs=
p; Individual Submission
Number of pages: 6
URL:           =
  http://www.ietf.org/internet-=
drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-=
temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext=
-00
 
 
Abstract:
   This document defines a mechanism by which packets of Rea=
l-Time
   Tranport Protocol (RTP) video streams encoded with the VP=
8 codec can
   indicate, in an RTP header extension, the temporal layer =
information
   about the frame encoded in the RTP packet.  This inf=
ormation can be
   used in a middlebox performing bandwidth management of st=
reams
   without requiring it to decrypt the streams.


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

 

-- 
Regards,
Adam

 


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

 




_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf=
.org/mailman/listinfo/avtext

 

-- 
Regards,
Adam

 

-- 
Regards,
Adam




-- 
Regards,
Adam



-- 
Regards,
Adam
--_000_8BA7D4CEACFFE04BA2D902BF11719A83384A0F8Fnasanexd02fnaqu_-- From stewe@stewe.org Thu Jul 25 00:45:14 2013 Return-Path: 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 3D42B21F9287; Thu, 25 Jul 2013 00:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ILC7xfcMpgrG; Thu, 25 Jul 2013 00:45:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 4A99021F99CE; Thu, 25 Jul 2013 00:45:06 -0700 (PDT) Received: from BN1PR07MB183.namprd07.prod.outlook.com (10.242.216.148) by BN1PR07MB182.namprd07.prod.outlook.com (10.242.216.153) with Microsoft SMTP Server (TLS) id 15.0.731.12; Thu, 25 Jul 2013 07:44:58 +0000 Received: from BN1PR07MB183.namprd07.prod.outlook.com ([169.254.9.26]) by BN1PR07MB183.namprd07.prod.outlook.com ([169.254.9.54]) with mapi id 15.00.0731.000; Thu, 25 Jul 2013 07:44:51 +0000 From: Stephan Wenger To: Adam Fineberg , "Wang, Ye-Kui" Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOiQrYv+z3B69wuEOSedMUp37hRw== Date: Thu, 25 Jul 2013 07:44:50 +0000 Message-ID: In-Reply-To: <51F05B32.5080401@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [195.202.153.34] x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(51914003)(377424004)(13464003)(51444003)(2473001)(479174003)(377454003)(24454002)(189002)(199002)(49866001)(19580385001)(47976001)(74662001)(19580405001)(4396001)(74502001)(31966008)(66066001)(47736001)(50986001)(65816001)(83322001)(59766001)(79102001)(77982001)(51856001)(63696002)(56816003)(76786001)(15202345003)(36756003)(74706001)(76482001)(77096001)(16236675002)(81542001)(56776001)(80022001)(53806001)(76176001)(76796001)(46102001)(8558605003)(69226001)(83072001)(47446002)(74876001)(74366001)(19580395003)(81342001)(54316002)(54356001)(16406001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR07MB182; H:BN1PR07MB183.namprd07.prod.outlook.com; CLIP:195.202.153.34; RD:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE169EA79FC3Cstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:45:14 -0000 --_000_CE169EA79FC3Cstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I thought about this a bit more. I think that one sensible document struct= ure may be as follows: (1) generic structure of scalability/pruning information to an RTP header e= xtension (to be worked on in avtext). (2) mapping of codec-specific features to the generic structure. As a loca= tion, I would suggest that (for new codecs) the RTP payload specs are the r= ight document. For codecs with existing RTP payload specs, a short doc tha= t updates the payload spec would be the right place, or a revision of the p= ayload spec itself if that needs to be done anyway. This would bundle all = the codec-specifics to one document. This document structure, and the philosophy behind it, would allow the desi= gn of a generic RTP stack that could take advantage of scalability features= independently of the scalable codec actually in use. I believe that such = an advantage outweighs the possible advantage of quick standardization of a= more specific approach as proposed in Adam's draft. That said, we need to= get the design of the generic structure right such that it is indeed usefu= l, ideally for all present and hopefully for a large subset of future codec= s. As for the specs involved: -H.264 SVC, H.265, and VP8 have payload format RFCs or reasonably stable dr= afts. -No one uses H.263 and MPEG-2 scalability, so we can ignore those two. -As Adam, I'm also not aware of a VP9 payload spec draft. However, my unde= rstanding is that VP9 will include a number of scalability features enabled= by multiple reference pictures and reference picture resampling. The latt= er is a somewhat different approach compared to the traditional scalability= implementations. I think that google planned to freeze the VP9 bitstream = a few weeks go, but I don't know whether that has happened. Without a stab= le spec and/or input from google/webm folks it will indeed be hard to addre= ss VP9's specific needs, if any. -There are a bunch of audio codecs that claim to be scalable. We should ha= ve a scope discussion on whether those need to be included here. Stephan From: Adam Fineberg > Date: Thursday, 25 July, 2013 00:54 To: "Wang, Ye-Kui" = > Cc: Bernard Aboba >, "avtext@ietf.org" >, "rtcweb@ietf.org" >, Justin Uberti > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt YK, I would appreciate your collaboration. Which codecs are you referring to w= hen you say "all existing standard scalable video codecs"? Regards, Adam On 7/24/13 3:32 PM, Wang, Ye-Kui wrote: If the group is to specify something generic, naturally it should be generi= c enough to cover at least all existing standard scalable video codecs if p= ossible. And I personally think that is possible and not difficult at all. = Thus, why limit to only a few scalable video codecs? I could provide some help here too if needed. BR, YK From:avtext-bounces@ietf.org [mailto:avtext= -bounces@ietf.org] On Behalf Of Adam Fineberg Sent: Wednesday, July 24, 2013 10:08 AM To: Bernard Aboba Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Bernard, I apologize if I come across as being difficult here but I stil am not seei= ng the benefits. Since the fields are not the same for the codecs, we will= be multiplexing the bits and that seems to me to add complexity rather tha= n add clarity. Also, I can't find an IETF VP9 document for the payload for= mat to reference. If the group thinks generalization is the right approach= I would appreciate some collaboration on getting the right bit definitions= for the other codecs. Regards, Adam On 7/23/13 12:07 PM, Bernard Aboba wrote: I do not think it is necessary to "support all forms of scalability for all= codecs". In fact, I would make that an explicit "non-goal". All that wa= s suggested is to try to create a single extension that supports a few comm= on cases. If it is possible to handle VP8, VP9 and H.264/SVC in a single = extension that would be sufficient. So why not limit it to that? ________________________________ Date: Tue, 23 Jul 2013 08:53:45 -0700 From: fineberg@vline.me To: stewe@stewe.org CC: juberti@google.com; bernard_aboba@hotmail.co= m; avtext@ietf.org; rtcweb@ietf.org Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach. = I'm not sure what we really gain by trying to capture all this in a single = header extension rather than one per that can succinctly explain the fields= without the complexity of multiplexing the bits. Thoughts? Regards, Adam On 7/19/13 3:44 PM, Stephan Wenger wrote: Hi, From: Adam Fineberg > Date: Friday, 19 July, 2013 15:12 To: Stephan Wenger > Cc: Justin Uberti >, Bernard = Aboba >, "avtex= t@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt Stephan, Thanks for the info and the reference. I'm not sure I follow as I'm not at= all familiar with H.265. I'll review the reference and see what I can fig= ure. StW: Good luck :-) It seems though to me that you are suggesting that except in the simple cas= e, that the data for H.265 would not be well suited to a header extension, = am I understanding you correctly? There is no reason the middlebox couldn'= t get out of band signaling of the VPS as you mention but that would not be= within the scope of this header extension. StW: well, if you would copy the layer_id into your header extension (just = as you need to do for the simple case), a really smart middle box could use= this information just as a decoder uses it, assuming that it intercepted t= he VPS in the first place. Insofar, I wouldn't rule out the second option = on technical grounds. Whether any of the actual products would bother to d= o that, ever, is another question. I think the case ought to be documented= , though. I can help drafting text. While we are at it: doing this right could mean that you need multiple spec= s. First, a generic header extension mechanism dedicated to side informati= on required for pruning of RTP packet streams=97ideally not only for scalab= le video, although that is the main customer today. And second, for each "= payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v= 2 (including scalable and 3D extensions, which are not yet finalized), VP8,= and VP9 (I know little about the latter), plus Daala, and whatnot) a mappi= ng of the bits available in the generic header extension to the bits in the= payload itself (NAL header and VPS in case of H.265, NALU header in SVC, a= nd the fields you mention for VP8). Stephan Any insights are appreciated. Regards, Adam On 7/19/13 8:33 AM, Stephan Wenger wrote: Hi, I also believe that 16 bits should be enough. For H.264 and VP8 that has a= lready been demonstrated. For H.265, some initial thoughts below. Apologi= es for the word-count. The scalable version of H265 (called SHVC) is currently under development. = The current working draft can be found here: http://phenix.int-evry.fr/jct= /doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. Therein, the o= ptions for defining layering structures are considerably more complex. To = start, we have 3 bits for the temporal ID in the NAL unit header of the H.2= 65 version 1 (HEVC) base specification (temporal scalability is already nic= ely supported in version 1). Just like in SVC. In the scalable extension,= the NAL unit header contains a six bit field that points into a data struc= ture known as "Video Parameter Set" (VPS). Inside the VPS, those six bits = are mapped to to a position in a directed graph (specified through "dimensi= on_id[][]"), which tells you about the reference relationship of the layer = in question and its parent layer. One can recursively follow the graph to = determine what used to be called dependency_id, quality_id, view_id, and wh= atnot. The six bit pointer field can (or: is to be when possible) organize= d by the encoder such that it is prudent for a middle box to throw away NAL= units (belonging to layers) with higher values of the six bit field first,= before throwing away NAL units with lower values. Relying on this feature= , 3+6 bits =3D=3D 9 bits should be fine for the header extension. That said, the ordering by the encoder is just a recommendation, and there = may well be cases where different pruning strategies may be advisable. For= example, a layering structure could be constructed that expands into two b= ranches, one using 2D scalable tools only, the other including view_id for = multi view coding. By looking at the six bit field alone, a middle box wil= l not be able to meaningfully remove NAL units belonging to one of the bran= ches completely while pruning the other branch. In order to meaningfully d= eal with that scenario, there would be two options: one to represent the di= mension_id[][] (and associated control info) in the header extension, or re= quire the middle box to have access to the VPS and be able to interpret its= content. The further could take considerably more than 16 bits and we wou= ld be talking about a variable length data structure. The latter requires = the middle box to have state and a mechanism to intercept the VPS (through = signaling=97as the encrypted in-band VPS would not be useful under the assu= mption that the middle box does not have the key to the media=97which is th= e motivation of the draft in the first place). I personally don't mind at = all the second mechanism, as I'm a big fan of out-of-band parameter set tra= nsmission and any middle box must be in the signaling path anyway to meanin= gfully manipulate RTP. I do not like the first option due to its variable,= and possibly substantial, overhead. Stephan From: Justin Uberti > Date: Friday, 19 July, 2013 06:32 To: Bernard Aboba > Cc: "avtext@ietf.org" >, "rtcweb@ietf.org" > Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Agree those are the right codecs to design for. Since in each case there ar= e fairly low limits on the number of supported layers (i.e. 3 spatial layer= s for SVC), I think it should be possible to pack the temporal, spatial, qu= ality layer ids into 16 bits. On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba > wrote: If we can support VP8/9 as well as H.264/5 SVC that would be a start. It seems doable to me. On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" > wrote: Bernard, Are there other codecs you are thinking should be supported? If it's gener= alized I would think we want to be able to cover all known scalable codecs.= I'll look into the H264/SVC fields to see how to encode them in a generali= zed header. Regards, Adam On 7/18/13 7:40 PM, Bernard Aboba wrote: I think it may be possible to generalize this. For example, for H.264/SVC = which can support temporal, spatial and quality scalability, you would need= the quality_id and dependency_id in addition to the temporal_id (what you = call the temporal layer index). ________________________________ Date: Thu, 18 Jul 2013 08:45:38 -0700 From: fineberg@vline.me To: bernard_aboba@hotmail.com CC: rtcweb@ietf.org; avtext@ietf.org Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt Bernard, Good question. I'm not familiar enough with the parameter requirements of = all other scalable codecs to be able to generalize. If you'd like to help = specify them, I'd be fine revising the draft to generalize. Regards, Adam On 7/17/13 8:26 PM, Bernard Aboba wrote: Since the need is not codec specific (e.g. it arises with any codec support= ing temporal, spatial and quality scalability), why a VP8-specific RTP extension? ________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message -------- Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.tx= t Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for= VP8 Temporal Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb -- Regards, Adam _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ avtext mailing list avtext@ietf.orghttps://www.ietf.org/mailman/listinf= o/avtext -- Regards, Adam -- Regards, Adam -- Regards, Adam -- Regards, Adam --_000_CE169EA79FC3Cstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <446B66DD7F4F094BA036DA39D17EBCF7@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,
I thought about this a bit more.  I think that one sensible docum= ent structure may be as follows:

(1) generic structure of scalability/pruning information to an RTP hea= der extension (to be worked on in avtext).
(2) mapping of codec-specific features to the generic structure.  = ;As a location, I would suggest that (for new codecs) the RTP payload specs= are the right document.  For codecs with existing RTP payload specs, = a short doc that updates the payload spec would be the right place, or a revision of the payload spec itself if that= needs to be done anyway.  This would bundle all the codec-specifics t= o one document.

This document structure, and the philosophy behind it, would allow the= design of a generic RTP stack that could take advantage of scalability fea= tures independently of the scalable codec actually in use.  I believe = that such an advantage outweighs the possible advantage of quick standardization of a more specific approach as= proposed in Adam's draft.  That said, we need to get the design of th= e generic structure right such that it is indeed useful, ideally for all pr= esent and hopefully for a large subset of future codecs.

As for the specs involved:
-H.264 SVC, H.265, and VP8 have payload format RFCs or reasonably stab= le drafts.
-No one uses H.263 and MPEG-2 scalability, so we can ignore those two.=
-As Adam, I'm also not aware of a VP9 payload spec draft.  Howeve= r, my understanding is that VP9 will include a number of scalability featur= es enabled by multiple reference pictures and reference picture resampling.=  The latter is a somewhat different approach compared to the traditional scalability implementations.  I = think that google planned to freeze the VP9 bitstream a few weeks go, but I= don't know whether that has happened.  Without a stable spec and/or i= nput from google/webm folks it will indeed be hard to address VP9's specific needs, if any.
-There are a bunch of audio codecs that claim to be scalable.  We= should have a scope discussion on whether those need to be included here.<= /div>

Stephan



From: Adam Fineberg <fineberg@vline.me>
Date: Thursday, 25 July, 2013 00:54=
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Justin Ube= rti <juberti@google.com> Subject: Re: [avtext] [rtcweb] Fwd:= New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.t= xt

YK,

I would appreciate your collaboration.  Which codecs are you referring= to when you say "all existing standard scalable video codecs"?

Regards,
Adam

On 7/24/13 3:32 PM, Wang, Ye-Kui wrote:

If the group is to specify somethi= ng generic, naturally it should be generic enough to cover at least all exi= sting standard scalable video codecs if possible. And I personally think that is possible and not difficult at = all. Thus, why limit to only a few scalable video codecs?=

 

I could provide some help here too= if needed.

 

BR, YK

 

From:avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Adam Fineberg
Sent: Wednesday, July 24, 2013 10:08 AM
To: Bernard Aboba
Cc: avtext@ietf.org; rtcwe= b@ietf.org; Justin Uberti
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Bernard,

I apologize if I come across as being difficult here but I stil am not seei= ng the benefits.  Since the fields are not the same for the codecs, we= will be multiplexing the bits and that seems to me to add complexity rathe= r than add clarity.  Also, I can't find an IETF VP9 document for the payload format to reference.  If the gro= up thinks generalization is the right approach I would appreciate some coll= aboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:=

I do not think it is = necessary to "support all forms of scalability for all codecs".&n= bsp;  In fact, I would make that an explicit "non-goal".&nbs= p; All that was suggested is to try to create a single extension that suppo= rts a few common cases.   If it is possible to handle VP8, VP9 and H= .264/SVC in a single extension that would be sufficient.  So why not l= imit it to that?

Date: Tue, 23 Jul 201= 3 08:53:45 -0700
From: fineber= g@vline.me
To: stewe@stewe= .org
CC: juberti@= google.com; berna= rd_aboba@hotmail.com; avtext@ietf.org= ; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fine= berg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows fo= r the specification of a header extension and the complexity introduced by = trying to generalize the header extension to support all forms of scalabili= ty for all codecs that the generalization might not be the best approach.  I'm not sure what we really gain by = trying to capture all this in a single header extension rather than one per= that can succinctly explain the fields without the complexity of multiplex= ing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:=

Hi,

 

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hot= mail.com>, "avtext@ietf.org" <avtext@iet= f.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for dra= ft-fineberg-avtext-temporal-layer-ext-00.txt

 

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm n= ot at all familiar with H.265.  I'll review the reference and see what= I can figure. 

 

StW: Good luck :-)  

 

It seems though to me that you are suggesting that except= in the simple case, that the data for H.265 would not be well suited to a = header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of = band signaling of the VPS as you mention but that would not be within the s= cope of this header extension.

 

StW: well, if you would copy the layer_id into your header exte= nsion (just as you need to do for the simple case), a really smart middle b= ox could use this information just as a decoder uses it, assuming that it intercepted the VPS in the f= irst place.  Insofar, I wouldn't rule out the second option on technic= al grounds.  Whether any of the actual products would bother to do tha= t, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.

While we are at it: doing this right could mean that you need m= ultiple specs.  First, a generic header extension mechanism dedicated = to side information required for pruning of RTP packet streams=97ideally not only for scalable video, although that= is the main customer today.  And second, for each "payload"= (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (inclu= ding scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and= whatnot) a mapping of the bits available in the generic header extension t= o the bits in the payload itself (NAL header and VPS in case of H.265, NALU= header in SVC, and the fields you mention for VP8).

 

Stephan



Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:

Hi,

I also believe that 16 bits should be enough.  For H= .264 and VP8 that has already been demonstrated.  For H.265, some init= ial thoughts below.  Apologies for the word-count.

 

The scalable version of H265 (called SHVC) is currently u= nder development.  The current working draft can be found here: <= a moz-do-not-send=3D"true" href=3D"http://phenix.int-evry.fr/jct/doc_end_us= er/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip" target=3D"_blank">http://p= henix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3= .zip.  Therein, the options for defining layering structures are considerab= ly more complex.  To start, we have 3 bits for the temporal ID in the = NAL unit header of the H.265 version 1 (HEVC) base specification (temporal = scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the N= AL unit header contains a six bit field that points into a data structure k= nown as "Video Parameter Set" (VPS).  Inside the VPS, those = six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about th= e reference relationship of the layer in question and its parent layer. &nb= sp;One can recursively follow the graph to determine what used to be called= dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized= by the encoder such that it is prudent for a middle box to throw away NAL = units (belonging to layers) with higher values of the six bit field first, = before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits =3D=3D 9 bits should b= e fine for the header extension.

 

That said, the ordering by the encoder is just a recommen= dation, and there may well be cases where different pruning strategies may = be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2= D scalable tools only, the other including view_id for multi view coding. &= nbsp;By looking at the six bit field alone, a middle box will not be able t= o meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In= order to meaningfully deal with that scenario, there would be two options:= one to represent the dimension_id[][] (and associated control info) in the= header extension, or require the middle box to have access to the VPS and be able to interpret its content.  = The further could take considerably more than 16 bits and we would be talki= ng about a variable length data structure.  The latter requires the mi= ddle box to have state and a mechanism to intercept the VPS (through signaling=97as the encrypted in-band VPS would = not be useful under the assumption that the middle box does not have the ke= y to the media=97which is the motivation of the draft in the first place). =  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmissi= on and any middle box must be in the signaling path anyway to meaningfully = manipulate RTP.  I do not like the first option due to its variable, a= nd possibly substantial, overhead.

 

Stephan   

 

 

From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-finebe= rg-avtext-temporal-layer-ext-00.txt

 

Agree those are the right codecs to design for. Since in = each case there are fairly low limits on the number of supported layers (i.= e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids int= o 16 bits.

 

On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.264/5 SVC=

that would be a start. It seems doable to me.<= /span>


On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vl= ine.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's = generalized I would think we want to be able to cover all known scalable co= decs. I'll look into the H264/SVC fields to see how to encode them in a gen= eralized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:

I think it may be possible= to generalize this.  For example, for H.264/SVC which can support tem= poral, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id= (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:= 45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avte= xt-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirement= s of all other scalable codecs to be able to generalize.  If you'd lik= e to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:

Since the need is not codec specific (e.g. it arises with= any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 

Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to= have access to the keys as well as the because of the added overhead of th= e decrypt/encrypt cycle. This draft proposes an RTP header extension that w= ill allow us to use the VP8 temporal layer information included in the header extension and therefore do forwar= ding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg

fineberg at vline.com

-------- Original Message --------

Subjec= t:

New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt

Date:<= o:p>

Tue, 09 Jul 2013 10:02:05 -0700

From:<= o:p>

internet-drafts at ietf.org

To:

Adam Fineberg <fineberg at vli= ne.com>

 




A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt<=
o:p>
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:         draft-fineberg-av=
text-temporal-layer-ext
Revision:         00

Title:            A =
Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer =
Information


Creation date:    2013-07-08


Group:            In=
dividual Submission


Number of pages: 6


URL:           =
  http=
://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00=
.txt


Status:          http://datatracker.ietf.org/do=
c/draft-fineberg-avtext-temporal-layer-ext


Htmlized:        http://tools.ietf.org/html/draft-fineberg-=
avtext-temporal-layer-ext-00


 


 


Abstract:


   This document defines a mechanism by which packets of Rea=
l-Time


   Tranport Protocol (RTP) video streams encoded with the VP=
8 codec can


   indicate, in an RTP header extension, the temporal layer =
information


   about the frame encoded in the RTP packet.  This inf=
ormation can be


   used in a middlebox performing bandwidth management of st=
reams


   without requiring it to decrypt the streams.


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

 

-- 
Regards,
Adam

 


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

 



_______________________________________________
avtext mailing list
avtext@iet=
f.orghttps://www.ietf.org/mailman/listinfo/avt=
ext

 

-- 
Regards,
Adam

 

-- 
Regards,
Adam



-- 
Regards,
Adam

--=20
Regards,
Adam
 --_000_CE169EA79FC3Cstewesteweorg_-- From ted.ietf@gmail.com Thu Jul 25 08:06:49 2013 Return-Path: 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 80E2121F9AE6 for ; Thu, 25 Jul 2013 08:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 7CRO3pJx1hGa for ; Thu, 25 Jul 2013 08:06:49 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFD921F9AC1 for ; Thu, 25 Jul 2013 08:06:49 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so4556781oah.21 for ; Thu, 25 Jul 2013 08:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XYsr9bJpNB8G1ZTqP2PrPwVDAdXEm+k1YUUFdRGQQwQ=; b=laDb8FcUFa62cZvr5SDhbvboWC3KaptPlefxSzO+JJYxGLPtyGw3zQ9OExO3bez5eQ jdBZT61ZRtUbLb+jNmnLi2vM+rT11LDvx4++53rOJNDIHvsMBXNE4pWAsmFf5KvN4/vB F9nzsa3PtBFyMbRU8wrFhpqUvI+4Jh9ea3fUaAV+48hTBM7ilxLyNHb1JoA/zGSYhkvo 9H3ZKqnF6zfj0lTdYuKViWqta8FKICy5bt20nVl7AkFjQKDeEUAA1EaLH6Q+xNK3JSbF qiK4SAsGqJEWbVX3iV5kfw0XV6MPy4yo4YVcJX7YF/JcUcL/f5f3Ecsan1M/WDkp38e/ sOFw== MIME-Version: 1.0 X-Received: by 10.50.6.16 with SMTP id w16mr383866igw.29.1374764808102; Thu, 25 Jul 2013 08:06:48 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Thu, 25 Jul 2013 08:06:47 -0700 (PDT) Date: Thu, 25 Jul 2013 08:06:47 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7ba97972096bac04e2576009 Subject: [rtcweb] Call for scribes for IETF87 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 15:06:49 -0000 --047d7ba97972096bac04e2576009 Content-Type: text/plain; charset=ISO-8859-1 If you are able to take minutes at IETF 87, please contact the chairs; we would ideally like two minute-takers per session. We will also be looking for folks to channel the jabber session to the room. thanks, Ted --047d7ba97972096bac04e2576009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you are able to take minutes at IETF 87, please contact the chairs; we w= ould ideally like two minute-takers per session.=A0 We will also be looking= for folks to channel the jabber session to the room.

thanks,
Ted
--047d7ba97972096bac04e2576009-- From jonathan@vidyo.com Thu Jul 25 09:49:53 2013 Return-Path: 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 1EA3121F969F; Thu, 25 Jul 2013 09:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 bQMyqRYVj-vQ; Thu, 25 Jul 2013 09:49:48 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5971721F965B; Thu, 25 Jul 2013 09:49:48 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DA71F5563E1; Thu, 25 Jul 2013 12:49:21 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2DA70556197; Thu, 25 Jul 2013 12:49:21 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Thu, 25 Jul 2013 12:48:58 -0400 From: Jonathan Lennox To: Adam Fineberg , "avtext@ietf.org" , "rtcweb@ietf.org" Date: Thu, 25 Jul 2013 12:49:25 -0400 Thread-Topic: [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: Ac6JU0u1DNwZuFpiQNmbMxDYxbXH3gAAWYOQ Message-ID: References: <20130709170205.4276.31863.idtracker@ietfa.amsl.com> <51E71C82.7090608@vline.me> In-Reply-To: <51E71C82.7090608@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C3759687E4991243A1A0BD44EAC823034E10AF5568BE235maillan_" MIME-Version: 1.0 Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:49:53 -0000 --_000_C3759687E4991243A1A0BD44EAC823034E10AF5568BE235maillan_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFkYW0g4oCTDQoNCihTcGVha2luZyBhcyBhbiBpbmRpdmlkdWFsLikNCg0KSSB0aGluayB0 aGVyZeKAmXMgYSBwcm9ibGVtIHdpdGggdGhlIHVzZSBjYXNlIGFzIHlvdeKAmXZlIGRlc2NyaWJl ZCBoZXJlLCB3aGljaCBJIHRoaW5rIGNhbGxzIGludG8gcXVlc3Rpb24gdGhlIHVzZWZ1bG5lc3Mg b2YgdGhlIHdob2xlIG1lY2hhbmlzbS4NCg0KQXMgSSB1bmRlcnN0YW5kIHlvdSwgeW914oCZcmUg cGxhbm5pbmcgdG8gc2VuZCBhIHNpbmdsZSBWUDggc3RyZWFtIGNvbnRhaW5pbmcgYWxsIHRoZSBs YXllcnMsIGFuZCB0aGVuIGhhdmUgYSBtZWRpYS1hd2FyZSBtaWRkbGVib3ggc2VsZWN0aXZlbHkg ZHJvcCBzb21lIG9mIHRoZSBzdHJlYW3igJlzIHBhY2tldHMgdG8gZG8gdGVtcG9yYWwgc2NhbGlu ZyB3aXRob3V0IG5lZWRpbmcgdGhlIG1pZGRsZWJveCB0byBiZSBpbiB0aGUgY3J5cHRvIGNvbnRl eHQuDQoNClVuZm9ydHVuYXRlbHksIFJUUCBkb2VzbuKAmXQgcmVhbGx5IGxldCB5b3UgZG8gdGhp cy4gIFRoZSBwcm9ibGVtIGlzIHRoYXQgYnkganVzdCBkcm9wcGluZyBwYWNrZXRzIHdpdGhvdXQg cmV3cml0aW5nIFJUUCBzZXF1ZW5jZSBudW1iZXJzIG9yIFJUQ1Agc2VuZGVyIHJlcG9ydHMsIHRo aXMgaXMgZ29pbmcgdG8gbG9vayBsaWtlIGVub3Jtb3VzIHBhY2tldCBsb3NzIHRvIFJUUCAod2hp Y2gsIGluIGEgc2Vuc2UsIGl0IGlzKS4gIEEgbWlkZGxlYm94IGxpa2UgdGhpcyDigJMgd2hpY2gg aXMgYWN0aW5nIGFzIGEgbWVkaWEtbW9kaWZ5aW5nIFJUUCB0cmFuc2xhdG9yLCBpbiBSVFAgdGVy bWlub2xvZ3kg4oCTIG5lZWRzIHRvIHJld3JpdGUgUlRQIGhlYWRlcnMgYW5kIFJUQ1Agc2VuZGVy IHJlcG9ydHMgaW4gb3JkZXIgdG8ga2VlcCB0aGUgc3RyZWFtIGFuZCBpdHMgbWV0YWRhdGEgY29u c2lzdGVudCBhbmQgdmFsaWQuDQoNClVuZm9ydHVuYXRlbHksIHRoZSB0cmFuc2xhdG9yIG5lZWRz IHRvIGhhdmUgdGhlIGNyeXB0byBrZXlzIGluIG9yZGVyIHRvIG1ha2UgdGhlc2UgbW9kaWZpY2F0 aW9ucywgc28gSeKAmW0gbm90IHN1cmUgdGhpcyBoZWFkZXIgZXh0ZW5zaW9uIGFkZHMgbXVjaCBi ZW5lZml0IG92ZXIganVzdCB2YWxpZGF0aW5nIHRoZSBhdXRoZW50aWNhdGlvbiwgZGVjcnlwdGlu ZyAoc2F5KSB0aGUgaW5pdGlhbCBibG9jayBvZiB0aGUgcGFja2V0ICh3aGVyZXZlciB0aGUgdGVt cG9yYWwgbGF5ZXIgaW5mb3JtYXRpb24gaXMga25vd24gdG8gYmUpLCBtb2RpZnlpbmcgdGhlIGhl YWRlcnMsIGFuZCB0aGVuIHJlLWF1dGhlbnRpY2F0aW5nIHRoZSBwYWNrZXQuDQoNCklzIHRoZXJl IHNvbWV0aGluZyBJ4oCZbSBtaXNzaW5nIGhlcmU/DQoNCkZyb206IEFkYW0gRmluZWJlcmcgW21h aWx0bzpmaW5lYmVyZ0B2bGluZS5tZV0NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxNywgMjAxMyA2 OjM3IFBNDQpUbzogYXZ0ZXh0QGlldGYub3JnDQpTdWJqZWN0OiBbYXZ0ZXh0XSBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxh eWVyLWV4dC0wMC50eHQNCg0KSGksDQoNCkknbSB3b3JraW5nIG9uIFdlYlJUQyBzZXJ2aWNlcyBh bmQgaGF2ZSBmb3VuZCB0aGF0IHdoaWxlIGRldmVsb3Bpbmcgc2VydmljZXMgdGhhdCBmb3J3YXJk IFZQOCB2aWRlbyBzdHJlYW1zIGlmIHdlIHdhbnQgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIFZQ OCB0ZW1wb3JhbCBzY2FsaW5nIHdlIG11c3QgZ2V0IHRoZSB0ZW1wb3JhbCBsYXllciBpbmZvcm1h dGlvbiBmcm9tIHRoZSBSVFAgaGVhZGVyIHdoaWNoIHJlcXVpcmVzIHVzIHRvIGRlY3J5cHQgdGhl IFNSVFAgcGFja2V0cy7vv73Cge+/vSBUaGlzIGlzIHVuZGVzaXJhYmxlIGJvdGggYmVjYXVzZSB0 aGUgbWlkZGxlYm94IG5lZWRzIHRvIGhhdmUgYWNlc3NzIHRvIHRoZSBrZXlzIGFzIHdlbGwgYXMg dGhlIGJlY2F1c2Ugb2YgdGhlIGFkZGVkIG92ZXJoZWFkIG9mIHRoZSBkZWNyeXB0L2VuY3J5cHQg Y3ljbGUu77+9woHvv70gVGhpcyBkcmFmdCBwcm9wb3NlcyBhbiBSVFAgaGVhZGVyIGV4dGVuc2lv biB0aGF0IHdpbGwgYWxsb3cgdXMgdG8gdXNlIHRoZSBWUDggdGVtcG9yYWwgbGF5ZXIgaW5mb3Jt YXRpb24gaW5jbHVkZWQgaW4gdGhlIGhlYWRlciBleHRlbnNpb24gYW5kIHRoZXJlZm9yZSBkbyBm b3J3YXJkaW5nIHdpdGhvdXQgU1JUUCBkZWNyeXB0aW9uLu+/vcKB77+9IENvbW1lbnRzIHdlbGNv bWUuDQoNClJlZ2FyZHMsDQpBZGFtIEZpbmViZXJnDQpmaW5lYmVyZ0B2bGluZS5jb208bWFpbHRv OmZpbmViZXJnQHZsaW5lLmNvbT4NCg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0t LQ0KU3ViamVjdDoNCg0KTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1maW5lYmVy Zy1hdnRleHQtdGVtcG9yYWwtbGF5ZXItZXh0LTAwLnR4dA0KDQpEYXRlOg0KDQpUdWUsIDA5IEp1 bCAyMDEzIDEwOjAyOjA1IC0wNzAwDQoNCkZyb206DQoNCmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KDQpUbzoNCg0KQWRhbSBGaW5lYmVy ZyA8ZmluZWJlcmdAdmxpbmUuY29tPjxtYWlsdG86ZmluZWJlcmdAdmxpbmUuY29tPg0KDQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXll ci1leHQtMDAudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWRhbSBG aW5lYmVyZyBhbmQgcG9zdGVkIHRvIHRoZQ0KDQpJRVRGIHJlcG9zaXRvcnkuDQoNCg0KDQpGaWxl bmFtZTogICAgICAgZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dA0KDQpS ZXZpc2lvbjogICAgICAgMDANCg0KVGl0bGU6ICAgICAgICAgIEEgUmVhbC1UaW1lIFRyYW5zcG9y dCBQcm90b2NvbCAoUlRQKSBIZWFkZXIgRXh0ZW5zaW9uIGZvciBWUDggVGVtcG9yYWwgTGF5ZXIg SW5mb3JtYXRpb24NCg0KQ3JlYXRpb24gZGF0ZTogIDIwMTMtMDctMDgNCg0KR3JvdXA6ICAgICAg ICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KDQpOdW1iZXIgb2YgcGFnZXM6IDYNCg0KVVJMOiAg ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1maW5l YmVyZy1hdnRleHQtdGVtcG9yYWwtbGF5ZXItZXh0LTAwLnR4dA0KDQpTdGF0dXM6ICAgICAgICAg IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRl bXBvcmFsLWxheWVyLWV4dA0KDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQtMDANCg0KDQoN Cg0KDQpBYnN0cmFjdDoNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbWVjaGFuaXNtIGJ5 IHdoaWNoIHBhY2tldHMgb2YgUmVhbC1UaW1lDQoNCiAgIFRyYW5wb3J0IFByb3RvY29sIChSVFAp IHZpZGVvIHN0cmVhbXMgZW5jb2RlZCB3aXRoIHRoZSBWUDggY29kZWMgY2FuDQoNCiAgIGluZGlj YXRlLCBpbiBhbiBSVFAgaGVhZGVyIGV4dGVuc2lvbiwgdGhlIHRlbXBvcmFsIGxheWVyIGluZm9y bWF0aW9uDQoNCiAgIGFib3V0IHRoZSBmcmFtZSBlbmNvZGVkIGluIHRoZSBSVFAgcGFja2V0LiAg VGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUNCg0KICAgdXNlZCBpbiBhIG1pZGRsZWJveCBwZXJmb3Jt aW5nIGJhbmR3aWR0aCBtYW5hZ2VtZW50IG9mIHN0cmVhbXMNCg0KICAgd2l0aG91dCByZXF1aXJp bmcgaXQgdG8gZGVjcnlwdCB0aGUgc3RyZWFtcy4NCg0KDQoNCg0KDQoNCg0KDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg0KDQo= --_000_C3759687E4991243A1A0BD44EAC823034E10AF5568BE235maillan_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGksIEFkYW0g4oCTPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz4oU3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVhbC4pPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIHRoaW5r IHRoZXJl4oCZcyBhIHByb2JsZW0gd2l0aCB0aGUgdXNlIGNhc2UgYXMgeW914oCZdmUgZGVzY3Jp YmVkIGhlcmUsIHdoaWNoIEkgdGhpbmsgY2FsbHMgaW50byBxdWVzdGlvbiB0aGUgdXNlZnVsbmVz cyBvZiB0aGUgd2hvbGUgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXMgSSB1bmRlcnN0 YW5kIHlvdSwgeW914oCZcmUgcGxhbm5pbmcgdG8gc2VuZCBhIHNpbmdsZSBWUDggc3RyZWFtIGNv bnRhaW5pbmcgYWxsIHRoZSBsYXllcnMsIGFuZCB0aGVuIGhhdmUgYSBtZWRpYS1hd2FyZSBtaWRk bGVib3ggc2VsZWN0aXZlbHkgZHJvcCBzb21lIG9mIHRoZSBzdHJlYW3igJlzIHBhY2tldHMgdG8g ZG8gdGVtcG9yYWwgc2NhbGluZyB3aXRob3V0IG5lZWRpbmcgdGhlIG1pZGRsZWJveCB0byBiZSBp biB0aGUgY3J5cHRvIGNvbnRleHQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VW5mb3J0dW5hdGVseSwg UlRQIGRvZXNu4oCZdCByZWFsbHkgbGV0IHlvdSBkbyB0aGlzLsKgIFRoZSBwcm9ibGVtIGlzIHRo YXQgYnkganVzdCBkcm9wcGluZyBwYWNrZXRzIHdpdGhvdXQgcmV3cml0aW5nIFJUUCBzZXF1ZW5j ZSBudW1iZXJzIG9yIFJUQ1Agc2VuZGVyIHJlcG9ydHMsIHRoaXMgaXMgZ29pbmcgdG8gbG9vayBs aWtlIGVub3Jtb3VzIHBhY2tldCBsb3NzIHRvIFJUUCAod2hpY2gsIGluIGEgc2Vuc2UsIGl0IGlz KS7CoCBBIG1pZGRsZWJveCBsaWtlIHRoaXMg4oCTIHdoaWNoIGlzIGFjdGluZyBhcyBhIG1lZGlh LW1vZGlmeWluZyBSVFAgdHJhbnNsYXRvciwgaW4gUlRQIHRlcm1pbm9sb2d5IOKAkyBuZWVkcyB0 byByZXdyaXRlIFJUUCBoZWFkZXJzIGFuZCBSVENQIHNlbmRlciByZXBvcnRzIGluIG9yZGVyIHRv IGtlZXAgdGhlIHN0cmVhbSBhbmQgaXRzIG1ldGFkYXRhIGNvbnNpc3RlbnQgYW5kIHZhbGlkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+VW5mb3J0dW5hdGVseSwgdGhlIHRyYW5zbGF0b3IgbmVlZHMgdG8g aGF2ZSB0aGUgY3J5cHRvIGtleXMgaW4gb3JkZXIgdG8gbWFrZSB0aGVzZSBtb2RpZmljYXRpb25z LCBzbyBJ4oCZbSBub3Qgc3VyZSB0aGlzIGhlYWRlciBleHRlbnNpb24gYWRkcyBtdWNoIGJlbmVm aXQgb3ZlciBqdXN0IHZhbGlkYXRpbmcgdGhlIGF1dGhlbnRpY2F0aW9uLCBkZWNyeXB0aW5nIChz YXkpIHRoZSBpbml0aWFsIGJsb2NrIG9mIHRoZSBwYWNrZXQgKHdoZXJldmVyIHRoZSB0ZW1wb3Jh bCBsYXllciBpbmZvcm1hdGlvbiBpcyBrbm93biB0byBiZSksIG1vZGlmeWluZyB0aGUgaGVhZGVy cywgYW5kIHRoZW4gcmUtYXV0aGVudGljYXRpbmcgdGhlIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPklzIHRoZXJlIHNvbWV0aGluZyBJ4oCZbSBtaXNzaW5nIGhlcmU/PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG86cD48L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 Y29sb3I6d2luZG93dGV4dCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0ZXh0 Jz4gQWRhbSBGaW5lYmVyZyBbbWFpbHRvOmZpbmViZXJnQHZsaW5lLm1lXSA8YnI+PGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgSnVseSAxNywgMjAxMyA2OjM3IFBNPGJyPjxiPlRvOjwvYj4gYXZ0ZXh0 QGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBbYXZ0ZXh0XSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dC0w MC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5IaSw8YnI+PGJyPkknbSB3 b3JraW5nIG9uIFdlYlJUQyBzZXJ2aWNlcyBhbmQgaGF2ZSBmb3VuZCB0aGF0IHdoaWxlIGRldmVs b3Bpbmcgc2VydmljZXMgdGhhdCBmb3J3YXJkIFZQOCB2aWRlbyBzdHJlYW1zIGlmIHdlIHdhbnQg dG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIFZQOCB0ZW1wb3JhbCBzY2FsaW5nIHdlIG11c3QgZ2V0 IHRoZSB0ZW1wb3JhbCBsYXllciBpbmZvcm1hdGlvbiBmcm9tIHRoZSBSVFAgaGVhZGVyIHdoaWNo IHJlcXVpcmVzIHVzIHRvIGRlY3J5cHQgdGhlIFNSVFAgcGFja2V0cy48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+woE8c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+IFRoaXMgaXMgdW5k ZXNpcmFibGUgYm90aCBiZWNhdXNlIHRoZSBtaWRkbGVib3ggbmVlZHMgdG8gaGF2ZSBhY2Vzc3Mg dG8gdGhlIGtleXMgYXMgd2VsbCBhcyB0aGUgYmVjYXVzZSBvZiB0aGUgYWRkZWQgb3ZlcmhlYWQg b2YgdGhlIGRlY3J5cHQvZW5jcnlwdCBjeWNsZS48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+woE8c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+IFRoaXMgZHJhZnQgcHJvcG9zZXMgYW4g UlRQIGhlYWRlciBleHRlbnNpb24gdGhhdCB3aWxsIGFsbG93IHVzIHRvIHVzZSB0aGUgVlA4IHRl bXBvcmFsIGxheWVyIGluZm9ybWF0aW9uIGluY2x1ZGVkIGluIHRoZSBoZWFkZXIgZXh0ZW5zaW9u IGFuZCB0aGVyZWZvcmUgZG8gZm9yd2FyZGluZyB3aXRob3V0IFNSVFAgZGVjcnlwdGlvbi48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+woE8 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz7vv708L3NwYW4+ IENvbW1lbnRzIHdlbGNvbWUuPGJyPjxicj5SZWdhcmRzLDxicj5BZGFtIEZpbmViZXJnPG86cD48 L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGEgaHJlZj0ibWFpbHRvOmZpbmViZXJn QHZsaW5lLmNvbSI+ZmluZWJlcmdAdmxpbmUuY29tPC9hPjxicj48YnI+LS0tLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvcD48dGFibGUgY2xhc3M9TXNvTm9ybWFs VGFibGUgYm9yZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wPjx0cj48dGQgbm93cmFw IHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29O b3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPlN1YmplY3Q6IDxv OnA+PC9vOnA+PC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4n PjxwIGNsYXNzPU1zb05vcm1hbD5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZp bmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQtMDAudHh0PG86cD48L286cD48L3A+PC90 ZD48L3RyPjx0cj48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAw aW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246 cmlnaHQnPjxiPkRhdGU6IDxvOnA+PC9vOnA+PC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGlu ZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD5UdWUsIDA5IEp1bCAyMDEzIDEw OjAyOjA1IC0wNzAwPG86cD48L286cD48L3A+PC90ZD48L3RyPjx0cj48dGQgbm93cmFwIHZhbGln bj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWwg YWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPkZyb206IDxvOnA+PC9vOnA+ PC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNz PU1zb05vcm1hbD48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+PC90ZD48L3RyPjx0cj48dGQg bm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFz cz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQnPjxiPlRvOiA8 bzpwPjwvbzpwPjwvYj48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu Jz48cCBjbGFzcz1Nc29Ob3JtYWw+QWRhbSBGaW5lYmVyZyA8YSBocmVmPSJtYWlsdG86ZmluZWJl cmdAdmxpbmUuY29tIj4mbHQ7ZmluZWJlcmdAdmxpbmUuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwv cD48L3RkPjwvdHI+PC90YWJsZT48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48cHJlPkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1maW5lYmVyZy1hdnRleHQtdGVtcG9yYWwtbGF5ZXItZXh0LTAwLnR4dDxvOnA+PC9v OnA+PC9wcmU+PHByZT5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFkYW0gRmlu ZWJlcmcgYW5kIHBvc3RlZCB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPjxwcmU+SUVURiByZXBvc2l0 b3J5LjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Rmls ZW5hbWU6wqDCoMKgwqDCoCAgZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4 dDxvOnA+PC9vOnA+PC9wcmU+PHByZT5SZXZpc2lvbjrCoMKgwqDCoMKgICAwMDxvOnA+PC9vOnA+ PC9wcmU+PHByZT5UaXRsZTrCoMKgwqDCoMKgwqDCoMKgICBBIFJlYWwtVGltZSBUcmFuc3BvcnQg UHJvdG9jb2wgKFJUUCkgSGVhZGVyIEV4dGVuc2lvbiBmb3IgVlA4IFRlbXBvcmFsIExheWVyIElu Zm9ybWF0aW9uPG86cD48L286cD48L3ByZT48cHJlPkNyZWF0aW9uIGRhdGU6ICAyMDEzLTA3LTA4 PG86cD48L286cD48L3ByZT48cHJlPkdyb3VwOsKgwqDCoMKgwqDCoMKgwqAgIEluZGl2aWR1YWwg U3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wcmU+PHByZT5OdW1iZXIgb2YgcGFnZXM6IDY8bzpwPjwv bzpwPjwvcHJlPjxwcmU+VVJMOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YSBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1maW5lYmVyZy1hdnRleHQtdGVt cG9yYWwtbGF5ZXItZXh0LTAwLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtZmluZWJlcmctYXZ0ZXh0LXRlbXBvcmFsLWxheWVyLWV4dC0wMC50eHQ8L2E+PG86 cD48L286cD48L3ByZT48cHJlPlN0YXR1czrCoMKgwqDCoMKgwqDCoMKgwqAgPGEgaHJlZj0iaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maW5lYmVyZy1hdnRleHQtdGVtcG9y YWwtbGF5ZXItZXh0Ij5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbmVi ZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQ8L2E+PG86cD48L286cD48L3ByZT48cHJlPkh0 bWxpemVkOsKgwqDCoMKgwqDCoMKgIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQtMDAiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpbmViZXJnLWF2dGV4dC10ZW1wb3JhbC1sYXllci1leHQt MDA8L2E+PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+QWJzdHJhY3Q6PG86cD48L286cD48L3ByZT48cHJl PsKgwqAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIHBhY2tldHMg b2YgUmVhbC1UaW1lPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgVHJhbnBvcnQgUHJvdG9jb2wg KFJUUCkgdmlkZW8gc3RyZWFtcyBlbmNvZGVkIHdpdGggdGhlIFZQOCBjb2RlYyBjYW48bzpwPjwv bzpwPjwvcHJlPjxwcmU+wqDCoCBpbmRpY2F0ZSwgaW4gYW4gUlRQIGhlYWRlciBleHRlbnNpb24s IHRoZSB0ZW1wb3JhbCBsYXllciBpbmZvcm1hdGlvbjxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKg IGFib3V0IHRoZSBmcmFtZSBlbmNvZGVkIGluIHRoZSBSVFAgcGFja2V0LsKgIFRoaXMgaW5mb3Jt YXRpb24gY2FuIGJlPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgdXNlZCBpbiBhIG1pZGRsZWJv eCBwZXJmb3JtaW5nIGJhbmR3aWR0aCBtYW5hZ2VtZW50IG9mIHN0cmVhbXM8bzpwPjwvbzpwPjwv cHJlPjxwcmU+wqDCoCB3aXRob3V0IHJlcXVpcmluZyBpdCB0byBkZWNyeXB0IHRoZSBzdHJlYW1z LjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+IMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxvOnA+PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT48cHJlPlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_C3759687E4991243A1A0BD44EAC823034E10AF5568BE235maillan_-- From martin.thomson@gmail.com Thu Jul 25 11:33:05 2013 Return-Path: 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 E804921F859A for ; Thu, 25 Jul 2013 11:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 GXt+RFPwDubU for ; Thu, 25 Jul 2013 11:33:05 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3BF21F90C9 for ; Thu, 25 Jul 2013 11:33:00 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so1307468wgg.28 for ; Thu, 25 Jul 2013 11:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=g9ALw6fBrgg+5RX5W1t0zuloW2Mm/blwTAwAAp8OR3c=; b=Dxiqm07OGlgMEBGCcdWX5KFUHKfLZ+cxWzHfmxr6rADGMp6EXSiFxmzBK5sNDui7Wd j2kBZpiDcuMWDg5DUSRCbZU2DQ+jfqmiNoTgTlx5a6PFqAEsCeAnbJUQGCt5MS1SMNX3 gCX4pqMoeC74gv88yxb584bJhhTyZJ+9uo95SMx+lGNzyOOZPpWGCxP12t4vJn3PK6F3 u0BjQviTjhSFaXxnRHvmoFF1hh9druznsP/k33l4uxKKKG7GTfhlOgOtPPDIyIuhVA4s IrzfjgEMjFwxuson21QKYfrt9la95QHs983I6EyR0BbNS6J2+mkp/W5JwmCXMxzKrCSk nJDg== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr31943295wjx.84.1374777175894; Thu, 25 Jul 2013 11:32:55 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 25 Jul 2013 11:32:55 -0700 (PDT) Date: Thu, 25 Jul 2013 11:32:55 -0700 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Security Architecture -07 review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 18:33:06 -0000 Just a short list of niggles and nits. I only reviewed the diff. The abstract has been truncated. Section 4.1, last paragraph on p11, s/[RFC6455]./[RFC6455].,/ Section 5.1 [...] Implementations MUST either choose to terminate the call or display a warning at that point. I don't recall the discussion that lead to this conclusion. I'm still in the "stop sending" camp on this. I understand that browsers already require machinery that notifies them of when a page transitions to becoming mixed content, because the lock icon tends to disappear on gmail all the time. So the only technical concern I can think of is the fact that this will appear as though there was a sudden massive packet loss event. I believe that's workable, as long as RTCP and connectivity checks continue. Section 5.2: [...] Note that it is unlikely that browsers would have an X.509 certificate, but servers might. This is a little over-simplified. 1. Servers will have an X.509, and that will need to be trusted somehow. 2. Clients will have X.509 certificates or else DTLS won't work, it's just that it's unlikely to be trusted for authentication of a domain name. I hope that we intend to talk about screen sharing at some point. That seems to be a bit of a big hole here. Even if all the mechanisms described are implemented, I don't believe that to be sufficient for this to be deployed. I tend to think that there needs to be a way to either opt-out (or preferably opt-in) of screen sharing. This probably crosses into W3C territory a bit too. Section 5.4: [...] Either such enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or the JS [...] The TURN only option at the browser level might be possible, but this is pretty unrealistic. Section 5.5: Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin. (This avoids creating a super-cookie.) The "unless" here is interesting. Why do you believe that caveat to be necessary? On a related note, we had some offline discussions about what it means to use the same key pair over time for the same site. Early Firefox implementations used a new key pair for every RTCPeerConnection, which, aside from being a little CPU-intensive, tends to make it impossible to audit calls after the fact. That is, it is useful to be able to ask the person you thought you were talking to for their certificate fingerprint to ensure that you really were talking to that person. However, the cookie issue is still a problem. Removing the certificate and key pair when cookies are cleared is necessary. [...] However, if Null ciphers are used, that MUST be presented to the user at the top-level UI. At what point did we decide that the Null cipher was acceptable? I thought that TLS pretty much prohibited the negotiation of the null cipher. I certainly wouldn't want to imply that this is an acceptable thing to do. From martin.thomson@gmail.com Thu Jul 25 11:59:53 2013 Return-Path: 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 8663221F89C3 for ; Thu, 25 Jul 2013 11:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6fwaSGrKl5mw for ; Thu, 25 Jul 2013 11:59:53 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id DBF9321F896D for ; Thu, 25 Jul 2013 11:59:52 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so2174723wib.14 for ; Thu, 25 Jul 2013 11:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O3L4FZkqPyso1cDszUMCekJ3XOoe4kEbXRwUxNHORIM=; b=n0b5eFfmby8U4zuaUA3lY+ZJMIqHmLs+L7KfIjqKkr7KDQX6UqmBL/VwepvSj3W4cc /cd0tJM/B3B94Bw6EjlrZ5UrypU4/xiDucsfq8/MOz5HZxgoB79tBsGLsuvcaZTADV4a HVCv2FuKajaW3iF2I5vSeN4nNDCkTgtZsksJLmxWRgYJIL9drqF0whUndSPni0aVJ0BV xYCMkyywaY5VPgGQxgTtKPq+3Pn9I4wsoiUSDnefMgTFO9PqKS33eVF18nhC3h5z/HoW 8faatyesycpjycInalcm8w4Vgtgp6+uEtH4CCX9sxmxV3BN2ZnQ0NgG4Si/hkmBXp0x4 /ZTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O3L4FZkqPyso1cDszUMCekJ3XOoe4kEbXRwUxNHORIM=; b=OSkwuFBH9TedOpmIwxuqM+ETKaaafbXrhLudhQjT/BGJxjkuAqbMLcwVFCGrhIBhDz 4RO47rowNdOoLiJQFw/rj7rkErJddgzBAk54KVfZ+eCRhGktqLN4bD6d+iCm6KygPBQQ eYgvi7ylfSsaoHeSeu0YNzL6ymAurkVKRssoDj9JP9xbRTISdtPw1IS9ttyAE8iAHmjv vBXjDhgmeBiSBTZwAh63aMiu5ysgHMHx/MadHDzT8WDYgbWIUb2Y9sZShT2/fKYZuwzz xJ6hXGlhyKzrBB/mdWZ1/7OYMWRKk4osIwn0OXY8uuUq1afRYqUL4hJnfUXdfGFTNG6b y4tw== MIME-Version: 1.0 X-Received: by 10.180.39.236 with SMTP id s12mr3160561wik.14.1374778790814; Thu, 25 Jul 2013 11:59:50 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 25 Jul 2013 11:59:50 -0700 (PDT) Date: Thu, 25 Jul 2013 11:59:50 -0700 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [rtcweb] Security -05 review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 18:59:53 -0000 I should have read this before security-arch, because it mentions the need to remove persistent identifiers. It probably needs to be a little more specific than it is though. I also note a typo: s/Gmail/email/ (let the RFC editor add hyphens or capitalization or whatever, I can never work out how to type that one) Otherwise, the changes look OK to me. From martin.thomson@gmail.com Thu Jul 25 13:47:36 2013 Return-Path: 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 25F3C21F9377 for ; Thu, 25 Jul 2013 13:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TqWkzMlDZC1O for ; Thu, 25 Jul 2013 13:47:35 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7CC21F941F for ; Thu, 25 Jul 2013 13:47:34 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so75773wiv.14 for ; Thu, 25 Jul 2013 13:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Knm/24P29ox8LUyGXCpKjHR7g8DHBXxpJQVjQGjiRNY=; b=N4w2KFJprbRp80q1ysoAyaldPuWbqKrRiEyigsKJSC8F5sB5Rl8Vu1wJmlYU3QncIa JE5l1QaSOcFMEzl4p9o5XViJT9G1An7yklNytnpRTdKp2WtpJjv199w9kL2sG0CYzMJe bGYlyYfhZSpHRAQnwVxkzu+/+C6HnRl62y9SKagngWBBxaadrh6dSp934sL5LSQytmwk 66I2i3NUaVwKEX9UCdT9xPiqzbNLD99DsXZO2H4l+0nCZEEXxlH/BnlYx3XFkLWMDXwF SCG2QAb//CYyf9KdTMb9EjvKLTBsXdmw5Tv9tU6eFnL01hZTeOd9eA/c2yGoekumOs0U aXtg== MIME-Version: 1.0 X-Received: by 10.194.110.6 with SMTP id hw6mr32617629wjb.3.1374785253490; Thu, 25 Jul 2013 13:47:33 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 25 Jul 2013 13:47:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 13:47:33 -0700 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [rtcweb] Security Architecture -07 review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:47:36 -0000 On 25 July 2013 11:32, Martin Thomson wrote: > Section 5.2: > [...] Note that > it is unlikely that browsers would have an X.509 certificate, but > servers might. > > This is a little over-simplified. 1. Servers will have an X.509, and > that will need to be trusted somehow. 2. Clients will have X.509 > certificates or else DTLS won't work, it's just that it's unlikely to > be trusted for authentication of a domain name. Expanding on this a little, with a text proposal. Sadly, this didn't turn out to be easy. OLD: In addition, they SHOULD support requests for access that promise that media from this grant will be sent to a single communicating peer (obviously there could be other requests for other peers). E.g., "Call customerservice@ford.com". NEW: In addition, browsers SHOULD ... (Editorial only) OLD: The semantics of this request are that the media stream from the camera and microphone will only be routed through a connection which has been cryptographically verified (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP handshake) as being associated with the stated identity. NEW: An application that requests access that is limited in this way cannot access or modify the acquired media or send media to any destination other than the specified identity. The browser will prevent the media from being transmitted over a connection which has a cryptographically verified identity (see Section !). (I don't think that it's necessary to do anything more than cite the appropriate section. I would have liked to identify a peer-authentication section here, but Section 5.6 deals only with the IdP stuff. If this were my document, I'd promote 5.6 to a new top-level section and add a new 5.6 that deals with peer authentication of both forms. The existing text regarding domain name-based authentication is light-to-non-existent. e.g. 5.6. Peer Authentication Establishing the identity of a communication peer requires that DTLS-SRTP be used with X.509 certificates being presented by both peers. Two mechanisms are then possible: Identity provider: Most browsers do not customarily have domain names and X.509 certificates for those domains. [The new] Section 6 describes a mechanism whereby a cryptographic assertion binding a self-signed X.509 certificate to an identity specific to an identity prover can be created and verified. Domain name: An X.509 certificate that contains a subjectAltName containing a domain name can be verified using the procedures defined in RFC 6125. This option is, however, only likely to be feasible for organizations that operate servers, since it depends on use of a domain name. Whatever the underlying technology, the general principle is that the party which is being authenticated is NOT the signaling site [...] Feel free to completely rewrite, or ignore this, I'm not across all the sensitivities here. I do think that the IdP stuff is big enough to get its own section. I actually still think that it's a big enough concept that a dedicated document would have been a better choice, still.... Another possibility is to deal with this a little better in Section 3.1, which I note could use a better term than "Other users" to refer to media/real-time peers.) REMOVE: Note that it is unlikely that browsers would have an X.509 certificate, but servers might. KEEP?: Browsers servicing such requests SHOULD clearly indicate that identity to the user when asking for permission. The idea behind this type of permissions is that a user might have a fairly narrow list of peers he is willing to communicate with, e.g., "my mother" rather than "anyone on Facebook". Narrow permissions grants allow the browser to do that enforcement. (I'm sure about the 2119 SHOULD here. I think that there are several ways to think about this. For the most part, I believe that there's no need to make any sort of normative statement. Absence of an indication isn't going to disadvantage users, they just lose the opportunity to learn about restrictions. Non-normative text that suggests the UI is a different matter: applications will appreciate any feature that increases the chance of a user hitting "allow".) From dwing@cisco.com Thu Jul 25 14:55:07 2013 Return-Path: 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 807E421F9287 for ; Thu, 25 Jul 2013 14:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Kc6HGykRMC+J for ; Thu, 25 Jul 2013 14:55:03 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B852721F90A7 for ; Thu, 25 Jul 2013 14:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3618; q=dns/txt; s=iport; t=1374789300; x=1375998900; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=pR01V+XK3i26tqiYY+FvGnBmzcKAzUkvxG9BwRohTwc=; b=icnpRLqjUlzAgrMBeey/L9HUda2aE8Wkc/hnRsP2oMrRVNJUL7pGDeO/ AS8B7dD8IBbkJhkjJu9zZcHgwPT3F5TsbGACtrCvqhlPymY3yrolVJhOt n9GnPoluLd2KvBvKEDkMGMVWjtZMPYe2UexWFmnyHaOklDQUKhhI1VRW7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAJad8VGrRDoI/2dsb2JhbABagwY1vjGBFxZ0giQBAQEDAQEBATc0CwULCxI0IQYiDgYTh34DCQUNsCINiFoEjRWCNTMHgxJuA4kqjEyBaYwnhSaDNBw X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208";a="87223838" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 25 Jul 2013 21:55:00 +0000 Received: from sjc-vpn7-549.cisco.com (sjc-vpn7-549.cisco.com [10.21.146.37]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6PLsx0m019089; Thu, 25 Jul 2013 21:54:59 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Thu, 25 Jul 2013 14:54:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security Architecture -07 review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 21:55:07 -0000 On Jul 25, 2013, at 11:32 AM, Martin Thomson = wrote: > Just a short list of niggles and nits. I only reviewed the diff. >=20 > The abstract has been truncated. >=20 > Section 4.1, last paragraph on p11, s/[RFC6455]./[RFC6455].,/ >=20 > Section 5.1 > [...] Implementations MUST either > choose to terminate the call or display a warning at that point. >=20 > I don't recall the discussion that lead to this conclusion. I'm still > in the "stop sending" camp on this. I understand that browsers > already require machinery that notifies them of when a page > transitions to becoming mixed content, because the lock icon tends to > disappear on gmail all the time. So the only technical concern I can > think of is the fact that this will appear as though there was a > sudden massive packet loss event. I believe that's workable, as long > as RTCP and connectivity checks continue. >=20 > Section 5.2: > [...] Note that > it is unlikely that browsers would have an X.509 certificate, but > servers might. >=20 > This is a little over-simplified. 1. Servers will have an X.509, and > that will need to be trusted somehow. 2. Clients will have X.509 > certificates or else DTLS won't work, it's just that it's unlikely to > be trusted for authentication of a domain name. >=20 > I hope that we intend to talk about screen sharing at some point. > That seems to be a bit of a big hole here. Even if all the mechanisms > described are implemented, I don't believe that to be sufficient for > this to be deployed. I tend to think that there needs to be a way to > either opt-out (or preferably opt-in) of screen sharing. This > probably crosses into W3C territory a bit too. >=20 > Section 5.4: > [...] Either such > enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or > the JS [...] >=20 > The TURN only option at the browser level might be possible, but this > is pretty unrealistic. >=20 > Section 5.5: > Unless the user specifically configures an > external key pair, different key pairs MUST be used for each > origin. (This avoids creating a super-cookie.) >=20 > The "unless" here is interesting. Why do you believe that caveat to > be necessary? >=20 > On a related note, we had some offline discussions about what it means > to use the same key pair over time for the same site. Early Firefox > implementations used a new key pair for every RTCPeerConnection, > which, aside from being a little CPU-intensive, tends to make it > impossible to audit calls after the fact. That is, it is useful to be > able to ask the person you thought you were talking to for their > certificate fingerprint to ensure that you really were talking to that > person. >=20 > However, the cookie issue is still a problem. Removing the > certificate and key pair when cookies are cleared is necessary. Wrapping the DTLS handshake inside a DH exchange would achieve both = goals (preventing a super-cookie from being passively observed, as well = as giving key continuity). -d >=20 > [...] However, if Null ciphers are used, that MUST be presented to > the user at the top-level UI. >=20 > At what point did we decide that the Null cipher was acceptable? I > thought that TLS pretty much prohibited the negotiation of the null > cipher. I certainly wouldn't want to imply that this is an acceptable > thing to do. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From martin.thomson@gmail.com Thu Jul 25 16:12:14 2013 Return-Path: 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 0EF3621F8F07 for ; Thu, 25 Jul 2013 16:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BYpDO0QsthyQ for ; Thu, 25 Jul 2013 16:12:13 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5D52B21F8EB3 for ; Thu, 25 Jul 2013 16:12:13 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n11so196635wgh.2 for ; Thu, 25 Jul 2013 16:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OA7qyIWaxqbgOVD2MkD5T3Infg4pD4TU4JC4GzyUI3g=; b=Z5qj22ZgdIlPSEeiubcPC1s0Y6/UnRXaZsEqApRtHSJJBn0AbTQ9jVJKCfpSvarIJ4 4bQEH8ECc/R4c49AEHvL6RpXkgW7ppSrl1cdW498UduAp/y3Xy/ee5AH6sTMMPhfOhtw b9oOX8GkN78xu1rJjQJ47h5z/xKmZHKd1B8q/itw6mGKQcDqZc/C3a5ts0LlcBJhCDDV miEmQaBQ+02wsETN2CQKtpx5u4o3eBChV6ww6FS0LvM887RUerjZyaSEJ2qyaLenzKTU 4kjN2imOsBdAvZ4gyY8/hnZdIGKG8iweJLVECFh9zKJNSLJP51dRt4i+CakmTjYAjLu0 YQAQ== MIME-Version: 1.0 X-Received: by 10.180.83.163 with SMTP id r3mr3752346wiy.10.1374793930923; Thu, 25 Jul 2013 16:12:10 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 25 Jul 2013 16:12:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 16:12:10 -0700 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security Architecture -07 review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 23:12:14 -0000 On 25 July 2013 14:54, Dan Wing wrote: >> However, the cookie issue is still a problem. Removing the >> certificate and key pair when cookies are cleared is necessary. > > Wrapping the DTLS handshake inside a DH exchange would achieve both goals (preventing a super-cookie from being passively observed, as well as giving key continuity). For passive observers, yes, but I'm not that concerned about them. After all, they are seeing the flow, so can make all sorts of inferences based on the flow addressing. The concern is the first party, who gets the certificate. Using DH isn't going to fix that. From dwing@cisco.com Thu Jul 25 17:00:55 2013 Return-Path: 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 2842021F8F29 for ; Thu, 25 Jul 2013 17:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 0-Bvb9yoBYqT for ; Thu, 25 Jul 2013 17:00:49 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DC61321F84BB for ; Thu, 25 Jul 2013 17:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=923; q=dns/txt; s=iport; t=1374796850; x=1376006450; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=FsmQUznaHtewGcsZFmlGlSPGbYa+qUR4Ix8toHebIKc=; b=ExsLQBxeA9IVy9UfJyBz0scHwMOqveGG+NeipURmbuo9dzedyG9LlQen NVBZ04iEIt6rlem+Dg3lQHJNlzzcl3wW5TwFqbEefHTIV9nCwP+23IF/W 0prRrRZVy2IPJha0OzY5dlwT56UAD7jG1Qsi4542y/EYh9WAzRDdBKa2M s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAN268VGrRDoH/2dsb2JhbABagwaDSrsfgRQWdIIkAQEBAwE6PwULCxIGLiEoDgYTh34DCQWwKg2IXo0VgjUzB4MSbgOJKoxMgWmMJ4UmgzQc X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208";a="87235063" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 26 Jul 2013 00:00:49 +0000 Received: from sjc-vpn7-2043.cisco.com (sjc-vpn7-2043.cisco.com [10.21.151.251]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6Q00mF3002452; Fri, 26 Jul 2013 00:00:48 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Thu, 25 Jul 2013 17:00:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3F737E1C-BBF9-4399-8B7D-B50FB4A2FFC0@cisco.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security Architecture -07 review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 00:00:55 -0000 On Jul 25, 2013, at 4:12 PM, Martin Thomson = wrote: > On 25 July 2013 14:54, Dan Wing wrote: >>> However, the cookie issue is still a problem. Removing the >>> certificate and key pair when cookies are cleared is necessary. >>=20 >> Wrapping the DTLS handshake inside a DH exchange would achieve both = goals (preventing a super-cookie from being passively observed, as well = as giving key continuity). >=20 > For passive observers, yes, but I'm not that concerned about them. > After all, they are seeing the flow, so can make all sorts of > inferences based on the flow addressing. But that doesn't mean we should purposefully leak even more information = at another layer. > The concern is the first party, who gets the certificate. Using DH > isn't going to fix that. Then you're arguing for "endpoint MUST NOT change its certificate". -d From martin.thomson@gmail.com Thu Jul 25 17:12:43 2013 Return-Path: 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 C0C8821F8F32 for ; Thu, 25 Jul 2013 17:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ag7HjeawgHb6 for ; Thu, 25 Jul 2013 17:12:43 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 120E821F8F29 for ; Thu, 25 Jul 2013 17:12:42 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so214650wiw.5 for ; Thu, 25 Jul 2013 17:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iqFm+qzCgQsF+2wyDICQ/vvcAjLd6iK//MFwjPae9as=; b=NPeM3wYmhscbvvgidRT9QTVDu3vYDlphN16WjTDwcm/l0FRr9mhjKHkM5iR8eU2qvD xAXCgKJv8hDsDcoTS7YMoFutpFjF4MUtw1KotTK1enZFqGGouPWrk6qky7MIB4PZnIPa 6yaRcum92OqoQFc3WY90REuSUDzWRm8fbslcYF5akocPYb8MxAVR5mBOVIliRseVhtZG yQLTjDn9xICXRvOmjyUWEisvFu/S1ddqjb8H+0EFfqKBg0tzaWdu+8vZ1/6IwDghfy/l +iCxrHD/7vQlD0n7rvK1WByektq5g9aPkZGVNmfFnBE0VuvWbTdDThchoY+U+doAVFJz NmoA== MIME-Version: 1.0 X-Received: by 10.194.77.99 with SMTP id r3mr32667054wjw.5.1374797559341; Thu, 25 Jul 2013 17:12:39 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 25 Jul 2013 17:12:39 -0700 (PDT) In-Reply-To: <3F737E1C-BBF9-4399-8B7D-B50FB4A2FFC0@cisco.com> References: <3F737E1C-BBF9-4399-8B7D-B50FB4A2FFC0@cisco.com> Date: Thu, 25 Jul 2013 17:12:39 -0700 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security Architecture -07 review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 00:12:43 -0000 On 25 July 2013 17:00, Dan Wing wrote: >> The concern is the first party, who gets the certificate. Using DH >> isn't going to fix that. > > Then you're arguing for "endpoint MUST NOT change its certificate". Nope. There are reasons to maintain a stable certificate (being able to audit old calls is helped by this, though a log of fingerprints used for calls over time might do the same, albeit a little less transparently; performance is another reason), just as there are reasons to change the certificate (privacy, mainly an ability to keep peers from linking calls). And yes, generally DH > not DH, but I'm not sure the benefits are huge, depending on what your threat model is. I was just pointing out that it doesn't actually help for the cases that I was really concerned about. The women's shelter case in particular. From dwing@cisco.com Thu Jul 25 17:34:33 2013 Return-Path: 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 CEC0E21F8749 for ; Thu, 25 Jul 2013 17:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 T9YVctOunObA for ; Thu, 25 Jul 2013 17:34:28 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C2A2921F86BE for ; Thu, 25 Jul 2013 17:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1948; q=dns/txt; s=iport; t=1374798868; x=1376008468; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yFfguRhPYuUe+b8VlHoDDkTjS8kiZEiry7vhfGj+s8c=; b=Un9D5haSuCsrp7czFE+nI8MT7AGGQtAyjXy8LXrElrN+p1YjqrVfMSBq paOF0utd7n29U8zYkl0zTqrmk3vop4EADWYn+l4MvzVhnEMIYr9lJkuPy jE9ryfBUZXUg5lay0nLCKuZNeohqnGVYVqgFKjI2lxuA2+yI3hX4fkYVt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAF7D8VGrRDoH/2dsb2JhbABRCYMGvmmBFBZ0giQBAQEDATo/BQsLEgYuISgOBhOHfgMJBbAoDYhejRWBMIEFMweDEm4DiSqMTIFpjCeFJoM0HA X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208";a="84221360" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 26 Jul 2013 00:34:28 +0000 Received: from sjc-vpn7-2043.cisco.com (sjc-vpn7-2043.cisco.com [10.21.151.251]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6Q0YR6K017162; Fri, 26 Jul 2013 00:34:27 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Thu, 25 Jul 2013 17:34:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <22027904-8F7D-4CB7-B002-39973D201D7A@cisco.com> References: <3F737E1C-BBF9-4399-8B7D-B50FB4A2FFC0@cisco.com> To: Martin Thomson X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security Architecture -07 review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 00:34:33 -0000 On Jul 25, 2013, at 5:12 PM, Martin Thomson = wrote: No comment on leaking information at other layers? We just improved the = RTCP CNAME to remove its leakage (draft-ietf-avtcore-6222bis), as an = example of reducing -- rather than expanding -- personally-identifyable = super-cookies. The DTLS handshake is over the same media path improved = by 6222bis. > On 25 July 2013 17:00, Dan Wing wrote: >>> The concern is the first party, who gets the certificate. Using DH >>> isn't going to fix that. >>=20 >> Then you're arguing for "endpoint MUST NOT change its certificate". >=20 > Nope. There are reasons to maintain a stable certificate (being able > to audit old calls is helped by this, though a log of fingerprints > used for calls over time might do the same, albeit a little less > transparently; performance is another reason), just as there are > reasons to change the certificate (privacy, mainly an ability to keep > peers from linking calls). >=20 > And yes, generally DH > not DH, but I'm not sure the benefits are > huge, depending on what your threat model is. I was just pointing out > that it doesn't actually help for the cases that I was really > concerned about. The women's shelter case in particular. Thanks for the explanation. I concur the public/private key needs a way = to be destroyed and a new one generated.=20 We could envision a more sophisticated mechanism, based on lots of = different criteria, where different public/private key pairs are used = and where some are destroyed immediately after certain calls. For = example, I might want to use a public/private key pair for all of my = work calls and leave that static (as I want that identity to stick with = me) but an ephemeral, one-time-only public/private key pair when not = engaging in phone calls related to my work, such as calling my = psychologist. -d From fineberg@vline.me Thu Jul 25 20:35:17 2013 Return-Path: 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 1FA1421F8C66; Thu, 25 Jul 2013 20:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 F-att3ZLJR-P; Thu, 25 Jul 2013 20:35:16 -0700 (PDT) Received: from cat2.kjsl.com (cat2.kjsl.com [IPv6:2001:1868:2001::30]) by ietfa.amsl.com (Postfix) with ESMTP id C8BA121F8476; Thu, 25 Jul 2013 20:35:14 -0700 (PDT) Received: from Adam-Finebergs-MacBook-Pro-2.local (75-25-130-225.lightspeed.sjcpca.sbcglobal.net [75.25.130.225]) (Authenticated sender: fineberg) by cat2.kjsl.com (Postfix) with ESMTP id B38AC12550A; Thu, 25 Jul 2013 23:35:11 -0400 (EDT) Message-ID: <51F1EE6E.4060408@vline.me> Date: Thu, 25 Jul 2013 20:35:10 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jonathan Lennox References: <20130709170205.4276.31863.idtracker@ietfa.amsl.com> <51E71C82.7090608@vline.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090908010601070603080408" Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 03:35:17 -0000 This is a multi-part message in MIME format. --------------090908010601070603080408 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Jonathan, Thanks for the feedback. You are of course correct, I'm not sure why I forgot about the authentication of the RTP header. The intent was not to have to perform the crypto on the payload of course but it would still require header changes which therefore needs the header re-authenticated. Regards, Adam On 7/25/13 9:49 AM, Jonathan Lennox wrote: > > Hi, Adam – > > (Speaking as an individual.) > > I think there’s a problem with the use case as you’ve described here, > which I think calls into question the usefulness of the whole mechanism. > > As I understand you, you’re planning to send a single VP8 stream > containing all the layers, and then have a media-aware middlebox > selectively drop some of the stream’s packets to do temporal scaling > without needing the middlebox to be in the crypto context. > > Unfortunately, RTP doesn’t really let you do this. The problem is > that by just dropping packets without rewriting RTP sequence numbers > or RTCP sender reports, this is going to look like enormous packet > loss to RTP (which, in a sense, it is). A middlebox like this – which > is acting as a media-modifying RTP translator, in RTP terminology – > needs to rewrite RTP headers and RTCP sender reports in order to keep > the stream and its metadata consistent and valid. > > Unfortunately, the translator needs to have the crypto keys in order > to make these modifications, so I’m not sure this header extension > adds much benefit over just validating the authentication, decrypting > (say) the initial block of the packet (wherever the temporal layer > information is known to be), modifying the headers, and then > re-authenticating the packet. > > Is there something I’m missing here? > > *From:*Adam Fineberg [mailto:fineberg@vline.me] > *Sent:* Wednesday, July 17, 2013 6:37 PM > *To:* avtext@ietf.org > *Subject:* [avtext] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > Hi, > > I'm working on WebRTC services and have found that while developing > services that forward VP8 video streams if we want to take advantage > of the VP8 temporal scaling we must get the temporal layer information > from the RTP header which requires us to decrypt the SRTP packets.�Â� > This is undesirable both because the middlebox needs to have acesss to > the keys as well as the because of the added overhead of the > decrypt/encrypt cycle.�Â� This draft proposes an RTP header extension > that will allow us to use the VP8 temporal layer information included > in the header extension and therefore do forwarding without SRTP > decryption.�Â� Comments welcome. > > Regards, > Adam Fineberg > > fineberg@vline.com > > -------- Original Message -------- > > *Subject: * > > > > New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > *Date: * > > > > Tue, 09 Jul 2013 10:02:05 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *To: * > > > > Adam Fineberg > > A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt > has been successfully submitted by Adam Fineberg and posted to the > IETF repository. > > Filename: draft-fineberg-avtext-temporal-layer-ext > Revision: 00 > Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt > Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext > Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 > > > Abstract: > This document defines a mechanism by which packets of Real-Time > Tranport Protocol (RTP) video streams encoded with the VP8 codec can > indicate, in an RTP header extension, the temporal layer information > about the frame encoded in the RTP packet. This information can be > used in a middlebox performing bandwidth management of streams > without requiring it to decrypt the streams. > > > > > The IETF Secretariat > > --------------090908010601070603080408 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Jonathan,

Thanks for the feedback.  You are of course correct, I'm not sure why I forgot about the authentication of the RTP header.  The intent was not to have to perform the crypto on the payload of course but it would still require header changes which therefore needs the header re-authenticated.

Regards,
Adam

On 7/25/13 9:49 AM, Jonathan Lennox wrote:

Hi, Adam –

 

(Speaking as an individual.)

 

I think there’s a problem with the use case as you’ve described here, which I think calls into question the usefulness of the whole mechanism.

 

As I understand you, you’re planning to send a single VP8 stream containing all the layers, and then have a media-aware middlebox selectively drop some of the stream’s packets to do temporal scaling without needing the middlebox to be in the crypto context.

 

Unfortunately, RTP doesn’t really let you do this.  The problem is that by just dropping packets without rewriting RTP sequence numbers or RTCP sender reports, this is going to look like enormous packet loss to RTP (which, in a sense, it is).  A middlebox like this – which is acting as a media-modifying RTP translator, in RTP terminology – needs to rewrite RTP headers and RTCP sender reports in order to keep the stream and its metadata consistent and valid.

 

Unfortunately, the translator needs to have the crypto keys in order to make these modifications, so I’m not sure this header extension adds much benefit over just validating the authentication, decrypting (say) the initial block of the packet (wherever the temporal layer information is known to be), modifying the headers, and then re-authenticating the packet.

 

Is there something I’m missing here?

                                                                                                                                                                                                                                                        

From: Adam Fineberg [mailto:fineberg@vline.me]
Sent: Wednesday, July 17, 2013 6:37 PM
To: avtext@ietf.org
Subject: [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets.�� This is undesirable both because the middlebox needs to have acesss to the keys as well as the because of the added overhead of the decrypt/encrypt cycle.�� This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption.�� Comments welcome.

Regards,
Adam Fineberg

fineberg@vline.com

-------- Original Message --------

Subject:

New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Date:

Tue, 09 Jul 2013 10:02:05 -0700

From:

internet-drafts@ietf.org

To:

Adam Fineberg <fineberg@vline.com>

 

A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:       draft-fineberg-avtext-temporal-layer-ext
Revision:       00
Title:          A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:  2013-07-08
Group:          Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00
 
 
Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.
 
                                                                                  
 
 
The IETF Secretariat
 

 


--------------090908010601070603080408-- From fineberg@vline.me Fri Jul 26 06:14:32 2013 Return-Path: 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 A8A2621F95DC; Fri, 26 Jul 2013 06:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 lTfy3wD58am0; Fri, 26 Jul 2013 06:14:29 -0700 (PDT) Received: from cat2.kjsl.com (cat2.kjsl.com [IPv6:2001:1868:2001::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4A01221F95BD; Fri, 26 Jul 2013 06:14:29 -0700 (PDT) Received: from Adam-Finebergs-MacBook-Pro-2.local (75-25-130-225.lightspeed.sjcpca.sbcglobal.net [75.25.130.225]) (Authenticated sender: fineberg) by cat2.kjsl.com (Postfix) with ESMTP id 453A212550C; Fri, 26 Jul 2013 09:14:26 -0400 (EDT) Message-ID: <51F27631.7060709@vline.me> Date: Fri, 26 Jul 2013 06:14:25 -0700 From: Adam Fineberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040608040800000106080000" Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 13:14:32 -0000 This is a multi-part message in MIME format. --------------040608040800000106080000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Stephan, This seems like a reasonable approach. I like your point about designing the RTP stack to generically handle scalability features. My concern is complexity and overhead for what should be a very lightweight process however generalizing seems to be the consensus so that should be the direction forward. Regards, Adam On 7/25/13 12:44 AM, Stephan Wenger wrote: > Hi, > I thought about this a bit more. I think that one sensible document > structure may be as follows: > > (1) generic structure of scalability/pruning information to an RTP > header extension (to be worked on in avtext). > (2) mapping of codec-specific features to the generic structure. As a > location, I would suggest that (for new codecs) the RTP payload specs > are the right document. For codecs with existing RTP payload specs, a > short doc that updates the payload spec would be the right place, or a > revision of the payload spec itself if that needs to be done anyway. > This would bundle all the codec-specifics to one document. > > This document structure, and the philosophy behind it, would allow the > design of a generic RTP stack that could take advantage of scalability > features independently of the scalable codec actually in use. I > believe that such an advantage outweighs the possible advantage of > quick standardization of a more specific approach as proposed in > Adam's draft. That said, we need to get the design of the generic > structure right such that it is indeed useful, ideally for all present > and hopefully for a large subset of future codecs. > > As for the specs involved: > -H.264 SVC, H.265, and VP8 have payload format RFCs or reasonably > stable drafts. > -No one uses H.263 and MPEG-2 scalability, so we can ignore those two. > -As Adam, I'm also not aware of a VP9 payload spec draft. However, my > understanding is that VP9 will include a number of scalability > features enabled by multiple reference pictures and reference picture > resampling. The latter is a somewhat different approach compared to > the traditional scalability implementations. I think that google > planned to freeze the VP9 bitstream a few weeks go, but I don't know > whether that has happened. Without a stable spec and/or input from > google/webm folks it will indeed be hard to address VP9's specific > needs, if any. > -There are a bunch of audio codecs that claim to be scalable. We > should have a scope discussion on whether those need to be included here. > > Stephan > > > > From: Adam Fineberg > > Date: Thursday, 25 July, 2013 00:54 > To: "Wang, Ye-Kui" > > Cc: Bernard Aboba >, "avtext@ietf.org > " >, > "rtcweb@ietf.org " >, Justin Uberti > > Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for > draft-fineberg-avtext-temporal-layer-ext-00.txt > > YK, > > I would appreciate your collaboration. Which codecs are you referring > to when you say "all existing standard scalable video codecs"? > > Regards, > Adam > > On 7/24/13 3:32 PM, Wang, Ye-Kui wrote: >> >> If the group is to specify something generic, naturally it should be >> generic enough to cover at least all existing standard scalable video >> codecs if possible. And I personally think that is possible and not >> difficult at all. Thus, why limit to only a few scalable video codecs? >> >> I could provide some help here too if needed. >> >> BR, YK >> >> *From:*avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] *On >> Behalf Of *Adam Fineberg >> *Sent:* Wednesday, July 24, 2013 10:08 AM >> *To:* Bernard Aboba >> *Cc:* avtext@ietf.org; rtcweb@ietf.org; Justin Uberti >> *Subject:* Re: [avtext] [rtcweb] Fwd: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Bernard, >> >> I apologize if I come across as being difficult here but I stil am >> not seeing the benefits. Since the fields are not the same for the >> codecs, we will be multiplexing the bits and that seems to me to add >> complexity rather than add clarity. Also, I can't find an IETF VP9 >> document for the payload format to reference. If the group thinks >> generalization is the right approach I would appreciate some >> collaboration on getting the right bit definitions for the other codecs. >> >> Regards, >> Adam >> >> On 7/23/13 12:07 PM, Bernard Aboba wrote: >> >> I do not think it is necessary to "support all forms of >> scalability for all codecs". In fact, I would make that an >> explicit "non-goal". All that was suggested is to try to create >> a single extension that supports a few common cases. If it is >> possible to handle VP8, VP9 and H.264/SVC in a single extension >> that would be sufficient. So why not limit it to that? >> >> ------------------------------------------------------------------------ >> >> Date: Tue, 23 Jul 2013 08:53:45 -0700 >> From: fineberg@vline.me >> To: stewe@stewe.org >> CC: juberti@google.com ; >> bernard_aboba@hotmail.com ; >> avtext@ietf.org ; rtcweb@ietf.org >> >> Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> I've been thinking about this and given the ease at which RFC5285 >> allows for the specification of a header extension and the >> complexity introduced by trying to generalize the header >> extension to support all forms of scalability for all codecs that >> the generalization might not be the best approach. I'm not sure >> what we really gain by trying to capture all this in a single >> header extension rather than one per that can succinctly explain >> the fields without the complexity of multiplexing the bits. >> >> Thoughts? >> >> Regards, >> Adam >> >> On 7/19/13 3:44 PM, Stephan Wenger wrote: >> >> Hi, >> >> *From: *Adam Fineberg > > >> *Date: *Friday, 19 July, 2013 15:12 >> *To: *Stephan Wenger > >> *Cc: *Justin Uberti > >, Bernard Aboba >> > >, "avtext@ietf.org >> " > >, "rtcweb@ietf.org >> " > > >> *Subject: *Re: [avtext] [rtcweb] Fwd: New Version >> Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Stephan, >> >> Thanks for the info and the reference. I'm not sure I follow >> as I'm not at all familiar with H.265. I'll review the >> reference and see what I can figure. >> >> StW: Good luck :-) >> >> It seems though to me that you are suggesting that except in >> the simple case, that the data for H.265 would not be well >> suited to a header extension, am I understanding you >> correctly? There is no reason the middlebox couldn't get out >> of band signaling of the VPS as you mention but that would >> not be within the scope of this header extension. >> >> StW: well, if you would copy the layer_id into your header >> extension (just as you need to do for the simple case), a >> really smart middle box could use this information just as a >> decoder uses it, assuming that it intercepted the VPS in the >> first place. Insofar, I wouldn't rule out the second option >> on technical grounds. Whether any of the actual products >> would bother to do that, ever, is another question. I think >> the case ought to be documented, though. I can help drafting >> text. >> >> While we are at it: doing this right could mean that you need >> multiple specs. First, a generic header extension mechanism >> dedicated to side information required for pruning of RTP >> packet streams—ideally not only for scalable video, although >> that is the main customer today. And second, for each >> "payload" (at present we are talking about H.264/SVC, H.265v1 >> (HEVC), H.265v2 (including scalable and 3D extensions, which >> are not yet finalized), VP8, and VP9 (I know little about the >> latter), plus Daala, and whatnot) a mapping of the bits >> available in the generic header extension to the bits in the >> payload itself (NAL header and VPS in case of H.265, NALU >> header in SVC, and the fields you mention for VP8). >> >> Stephan >> >> >> >> Any insights are appreciated. >> >> Regards, >> Adam >> >> On 7/19/13 8:33 AM, Stephan Wenger wrote: >> >> Hi, >> >> I also believe that 16 bits should be enough. For H.264 >> and VP8 that has already been demonstrated. For H.265, >> some initial thoughts below. Apologies for the word-count. >> >> The scalable version of H265 (called SHVC) is currently >> under development. The current working draft can be >> found here: >> http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip. >> Therein, the options for defining layering structures >> are considerably more complex. To start, we have 3 bits >> for the temporal ID in the NAL unit header of the H.265 >> version 1 (HEVC) base specification (temporal scalability >> is already nicely supported in version 1). Just like in >> SVC. In the scalable extension, the NAL unit header >> contains a six bit field that points into a data >> structure known as "Video Parameter Set" (VPS). Inside >> the VPS, those six bits are mapped to to a position in a >> directed graph (specified through "dimension_id[][]"), >> which tells you about the reference relationship of the >> layer in question and its parent layer. One can >> recursively follow the graph to determine what used to be >> called dependency_id, quality_id, view_id, and whatnot. >> The six bit pointer field can (or: is to be when >> possible) organized by the encoder such that it is >> prudent for a middle box to throw away NAL units >> (belonging to layers) with higher values of the six bit >> field first, before throwing away NAL units with lower >> values. Relying on this feature, 3+6 bits == 9 bits >> should be fine for the header extension. >> >> That said, the ordering by the encoder is just a >> recommendation, and there may well be cases where >> different pruning strategies may be advisable. For >> example, a layering structure could be constructed that >> expands into two branches, one using 2D scalable tools >> only, the other including view_id for multi view coding. >> By looking at the six bit field alone, a middle box will >> not be able to meaningfully remove NAL units belonging to >> one of the branches completely while pruning the other >> branch. In order to meaningfully deal with that >> scenario, there would be two options: one to represent >> the dimension_id[][] (and associated control info) in the >> header extension, or require the middle box to have >> access to the VPS and be able to interpret its content. >> The further could take considerably more than 16 bits >> and we would be talking about a variable length data >> structure. The latter requires the middle box to have >> state and a mechanism to intercept the VPS (through >> signaling—as the encrypted in-band VPS would not be >> useful under the assumption that the middle box does not >> have the key to the media—which is the motivation of the >> draft in the first place). I personally don't mind at >> all the second mechanism, as I'm a big fan of out-of-band >> parameter set transmission and any middle box must be in >> the signaling path anyway to meaningfully manipulate RTP. >> I do not like the first option due to its variable, and >> possibly substantial, overhead. >> >> Stephan >> >> *From: *Justin Uberti > > >> *Date: *Friday, 19 July, 2013 06:32 >> *To: *Bernard Aboba > > >> *Cc: *"avtext@ietf.org " >> >, >> "rtcweb@ietf.org " >> > >> *Subject: *Re: [rtcweb] Fwd: New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Agree those are the right codecs to design for. Since in >> each case there are fairly low limits on the number of >> supported layers (i.e. 3 spatial layers for SVC), I think >> it should be possible to pack the temporal, spatial, >> quality layer ids into 16 bits. >> >> On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba >> > > wrote: >> >> If we can support VP8/9 as well as H.264/5 SVC >> >> that would be a start. It seems doable to me. >> >> >> On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" >> > wrote: >> >> Bernard, >> >> Are there other codecs you are thinking should be >> supported? If it's generalized I would think we want >> to be able to cover all known scalable codecs. I'll >> look into the H264/SVC fields to see how to encode >> them in a generalized header. >> >> Regards, >> Adam >> >> On 7/18/13 7:40 PM, Bernard Aboba wrote: >> >> I think it may be possible to generalize this. >> For example, for H.264/SVC which can support >> temporal, spatial and quality scalability, you >> would need the quality_id and dependency_id in >> addition to the temporal_id (what you call the >> temporal layer index). >> >> ------------------------------------------------------------------------ >> >> Date: Thu, 18 Jul 2013 08:45:38 -0700 >> From: fineberg@vline.me >> To: bernard_aboba@hotmail.com >> >> CC: rtcweb@ietf.org ; >> avtext@ietf.org >> Subject: Re: [rtcweb] Fwd: New Version >> Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Bernard, >> >> Good question. I'm not familiar enough with the >> parameter requirements of all other scalable >> codecs to be able to generalize. If you'd like to >> help specify them, I'd be fine revising the draft >> to generalize. >> >> Regards, >> Adam >> >> On 7/17/13 8:26 PM, Bernard Aboba wrote: >> >> Since the need is not codec specific (e.g. it >> arises with any codec supporting temporal, >> spatial and quality scalability), why >> a VP8-specific RTP extension? >> >> ------------------------------------------------------------------------ >> >> Date: Wed, 17 Jul 2013 17:09:46 -0700 >> From: fineberg@vline.me >> >> To: rtcweb@ietf.org >> Subject: [rtcweb] Fwd: New Version >> Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Hi, >> >> I'm working on WebRTC services and have found >> that while developing services that forward >> VP8 video streams if we want to take >> advantage of the VP8 temporal scaling we must >> get the temporal layer information from the >> RTP header which requires us to decrypt the >> SRTP packets. This is undesirable both >> because the middle-box needs to have access >> to the keys as well as the because of the >> added overhead of the decrypt/encrypt cycle. >> This draft proposes an RTP header extension >> that will allow us to use the VP8 temporal >> layer information included in the header >> extension and therefore do forwarding without >> SRTP decryption. Comments welcome. >> >> Regards, >> Adam Fineberg >> >> fineberg at vline.com >> >> >> -------- Original Message -------- >> >> *Subject:* >> >> >> >> New Version Notification for >> draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> *Date:* >> >> >> >> Tue, 09 Jul 2013 10:02:05 -0700 >> >> *From:* >> >> >> >> internet-drafts at ietf.org >> >> >> *To:* >> >> >> >> Adam Fineberg >> >> >> >> >> >> A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> has been successfully submitted by Adam Fineberg and posted to the >> >> IETF repository. >> >> >> >> Filename: draft-fineberg-avtext-temporal-layer-ext >> >> Revision: 00 >> >> Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information >> >> Creation date: 2013-07-08 >> >> Group: Individual Submission >> >> Number of pages: 6 >> >> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt >> >> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext >> >> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00 >> >> >> >> >> >> Abstract: >> >> This document defines a mechanism by which packets of Real-Time >> >> Tranport Protocol (RTP) video streams encoded with the VP8 codec can >> >> indicate, in an RTP header extension, the temporal layer information >> >> about the frame encoded in the RTP packet. This information can be >> >> used in a middlebox performing bandwidth management of streams >> >> without requiring it to decrypt the streams. >> >> >> _______________________________________________ >> rtcweb mailing list rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> -- >> >> Regards, >> >> Adam >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> >> avtext mailing list >> >> avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext >> >> --------------040608040800000106080000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Stephan,

This seems like a reasonable approach.  I like your point about designing the RTP stack to generically handle scalability features.  My concern is complexity and overhead for what should be a very lightweight process however generalizing seems to be the consensus so that should be the direction forward.

Regards,
Adam

On 7/25/13 12:44 AM, Stephan Wenger wrote:
Hi,
I thought about this a bit more.  I think that one sensible document structure may be as follows:

(1) generic structure of scalability/pruning information to an RTP header extension (to be worked on in avtext).
(2) mapping of codec-specific features to the generic structure.  As a location, I would suggest that (for new codecs) the RTP payload specs are the right document.  For codecs with existing RTP payload specs, a short doc that updates the payload spec would be the right place, or a revision of the payload spec itself if that needs to be done anyway.  This would bundle all the codec-specifics to one document.

This document structure, and the philosophy behind it, would allow the design of a generic RTP stack that could take advantage of scalability features independently of the scalable codec actually in use.  I believe that such an advantage outweighs the possible advantage of quick standardization of a more specific approach as proposed in Adam's draft.  That said, we need to get the design of the generic structure right such that it is indeed useful, ideally for all present and hopefully for a large subset of future codecs.

As for the specs involved:
-H.264 SVC, H.265, and VP8 have payload format RFCs or reasonably stable drafts.
-No one uses H.263 and MPEG-2 scalability, so we can ignore those two.
-As Adam, I'm also not aware of a VP9 payload spec draft.  However, my understanding is that VP9 will include a number of scalability features enabled by multiple reference pictures and reference picture resampling.  The latter is a somewhat different approach compared to the traditional scalability implementations.  I think that google planned to freeze the VP9 bitstream a few weeks go, but I don't know whether that has happened.  Without a stable spec and/or input from google/webm folks it will indeed be hard to address VP9's specific needs, if any.
-There are a bunch of audio codecs that claim to be scalable.  We should have a scope discussion on whether those need to be included here.

Stephan



From: Adam Fineberg <fineberg@vline.me>
Date: Thursday, 25 July, 2013 00:54
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Justin Uberti <juberti@google.com>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

YK,

I would appreciate your collaboration.  Which codecs are you referring to when you say "all existing standard scalable video codecs"?

Regards,
Adam

On 7/24/13 3:32 PM, Wang, Ye-Kui wrote:

If the group is to specify something generic, naturally it should be generic enough to cover at least all existing standard scalable video codecs if possible. And I personally think that is possible and not difficult at all. Thus, why limit to only a few scalable video codecs?

 

I could provide some help here too if needed.

 

BR, YK

 

From:avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Adam Fineberg
Sent: Wednesday, July 24, 2013 10:08 AM
To: Bernard Aboba
Cc: avtext@ietf.org; rtcweb@ietf.org; Justin Uberti
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Bernard,

I apologize if I come across as being difficult here but I stil am not seeing the benefits.  Since the fields are not the same for the codecs, we will be multiplexing the bits and that seems to me to add complexity rather than add clarity.  Also, I can't find an IETF VP9 document for the payload format to reference.  If the group thinks generalization is the right approach I would appreciate some collaboration on getting the right bit definitions for the other codecs.

Regards,
Adam

On 7/23/13 12:07 PM, Bernard Aboba wrote:

I do not think it is necessary to "support all forms of scalability for all codecs".   In fact, I would make that an explicit "non-goal".  All that was suggested is to try to create a single extension that supports a few common cases.   If it is possible to handle VP8, VP9 and H.264/SVC in a single extension that would be sufficient.  So why not limit it to that?

Date: Tue, 23 Jul 2013 08:53:45 -0700
From: fineberg@vline.me
To: stewe@stewe.org
CC: juberti@google.com; bernard_aboba@hotmail.com; avtext@ietf.org; rtcweb@ietf.org
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

I've been thinking about this and given the ease at which RFC5285 allows for the specification of a header extension and the complexity introduced by trying to generalize the header extension to support all forms of scalability for all codecs that the generalization might not be the best approach.  I'm not sure what we really gain by trying to capture all this in a single header extension rather than one per that can succinctly explain the fields without the complexity of multiplexing the bits.

Thoughts?

Regards,
Adam

On 7/19/13 3:44 PM, Stephan Wenger wrote:

Hi,

 

From: Adam Fineberg <fineberg@vline.me>
Date: Friday, 19 July, 2013 15:12
To: Stephan Wenger <stewe@stewe.org>
Cc: Justin Uberti <juberti@google.com>, Bernard Aboba <bernard_aboba@hotmail.com>, "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Stephan,

Thanks for the info and the reference.  I'm not sure I follow as I'm not at all familiar with H.265.  I'll review the reference and see what I can figure. 

 

StW: Good luck :-)  

 

It seems though to me that you are suggesting that except in the simple case, that the data for H.265 would not be well suited to a header extension, am I understanding you correctly?  There is no reason the middlebox couldn't get out of band signaling of the VPS as you mention but that would not be within the scope of this header extension.

 

StW: well, if you would copy the layer_id into your header extension (just as you need to do for the simple case), a really smart middle box could use this information just as a decoder uses it, assuming that it intercepted the VPS in the first place.  Insofar, I wouldn't rule out the second option on technical grounds.  Whether any of the actual products would bother to do that, ever, is another question.  I think the case ought to be documented, though.  I can help drafting text.

While we are at it: doing this right could mean that you need multiple specs.  First, a generic header extension mechanism dedicated to side information required for pruning of RTP packet streams—ideally not only for scalable video, although that is the main customer today.  And second, for each "payload" (at present we are talking about H.264/SVC, H.265v1 (HEVC), H.265v2 (including scalable and 3D extensions, which are not yet finalized), VP8, and VP9 (I know little about the latter), plus Daala, and whatnot) a mapping of the bits available in the generic header extension to the bits in the payload itself (NAL header and VPS in case of H.265, NALU header in SVC, and the fields you mention for VP8).

 

Stephan



Any insights are appreciated.

Regards,
Adam

On 7/19/13 8:33 AM, Stephan Wenger wrote:

Hi,

I also believe that 16 bits should be enough.  For H.264 and VP8 that has already been demonstrated.  For H.265, some initial thoughts below.  Apologies for the word-count.

 

The scalable version of H265 (called SHVC) is currently under development.  The current working draft can be found here: http://phenix.int-evry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC-M1008-v3.zip.  Therein, the options for defining layering structures are considerably more complex.  To start, we have 3 bits for the temporal ID in the NAL unit header of the H.265 version 1 (HEVC) base specification (temporal scalability is already nicely supported in version 1).  Just like in SVC.  In the scalable extension, the NAL unit header contains a six bit field that points into a data structure known as "Video Parameter Set" (VPS).  Inside the VPS, those six bits are mapped to to a position in a directed graph (specified through "dimension_id[][]"), which tells you about the reference relationship of the layer in question and its parent layer.  One can recursively follow the graph to determine what used to be called dependency_id, quality_id, view_id, and whatnot.  The six bit pointer field can (or: is to be when possible) organized by the encoder such that it is prudent for a middle box to throw away NAL units (belonging to layers) with higher values of the six bit field first, before throwing away NAL units with lower values.  Relying on this feature, 3+6 bits == 9 bits should be fine for the header extension.

 

That said, the ordering by the encoder is just a recommendation, and there may well be cases where different pruning strategies may be advisable.  For example, a layering structure could be constructed that expands into two branches, one using 2D scalable tools only, the other including view_id for multi view coding.  By looking at the six bit field alone, a middle box will not be able to meaningfully remove NAL units belonging to one of the branches completely while pruning the other branch.  In order to meaningfully deal with that scenario, there would be two options: one to represent the dimension_id[][] (and associated control info) in the header extension, or require the middle box to have access to the VPS and be able to interpret its content.  The further could take considerably more than 16 bits and we would be talking about a variable length data structure.  The latter requires the middle box to have state and a mechanism to intercept the VPS (through signaling—as the encrypted in-band VPS would not be useful under the assumption that the middle box does not have the key to the media—which is the motivation of the draft in the first place).  I personally don't mind at all the second mechanism, as I'm a big fan of out-of-band parameter set transmission and any middle box must be in the signaling path anyway to meaningfully manipulate RTP.  I do not like the first option due to its variable, and possibly substantial, overhead.

 

Stephan   

 

 

From: Justin Uberti <juberti@google.com>
Date: Friday, 19 July, 2013 06:32
To: Bernard Aboba <bernard_aboba@hotmail.com>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

 

Agree those are the right codecs to design for. Since in each case there are fairly low limits on the number of supported layers (i.e. 3 spatial layers for SVC), I think it should be possible to pack the temporal, spatial, quality layer ids into 16 bits.

 

On Fri, Jul 19, 2013 at 1:56 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

If we can support VP8/9 as well as H.264/5 SVC

that would be a start. It seems doable to me.


On Jul 18, 2013, at 8:34 PM, "Adam Fineberg" <fineberg@vline.me> wrote:

Bernard,

Are there other codecs you are thinking should be supported?  If it's generalized I would think we want to be able to cover all known scalable codecs. I'll look into the H264/SVC fields to see how to encode them in a generalized header.

Regards,
Adam

On 7/18/13 7:40 PM, Bernard Aboba wrote:

I think it may be possible to generalize this.  For example, for H.264/SVC which can support temporal, spatial and quality scalability, you would need the quality_id and dependency_id in addition to the temporal_id (what you call the temporal layer index).   

Date: Thu, 18 Jul 2013 08:45:38 -0700
From: fineberg@vline.me
To: bernard_aboba@hotmail.com
CC: rtcweb@ietf.org; avtext@ietf.org
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Bernard,

Good question.  I'm not familiar enough with the parameter requirements of all other scalable codecs to be able to generalize.  If you'd like to help specify them, I'd be fine revising the draft to generalize.

Regards,
Adam

On 7/17/13 8:26 PM, Bernard Aboba wrote:

Since the need is not codec specific (e.g. it arises with any codec supporting temporal, spatial and quality scalability), why
 a VP8-specific RTP extension?
 

Date: Wed, 17 Jul 2013 17:09:46 -0700
From: fineberg@vline.me
To: rtcweb@ietf.org
Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets. This is undesirable both because the middle-box needs to have access to the keys as well as the because of the added overhead of the decrypt/encrypt cycle. This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption. Comments welcome.

Regards,
Adam Fineberg

fineberg at vline.com

-------- Original Message --------

Subject:

New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Date:

Tue, 09 Jul 2013 10:02:05 -0700

From:

internet-drafts at ietf.org

To:

Adam Fineberg <fineberg at vline.com>

 




A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.
 
Filename:         draft-fineberg-avtext-temporal-layer-ext
Revision:         00
Title:            A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:    2013-07-08
Group:            Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00
 
 
Abstract:
   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.


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

 

-- 
Regards,
Adam

 


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

 



_______________________________________________
avtext mailing list
avtext@ietf.orghttps://www.ietf.org/mailman/listinfo/avtext


--------------040608040800000106080000-- From kaiduanx@gmail.com Fri Jul 26 06:42:59 2013 Return-Path: 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 29E1421F88FB; Fri, 26 Jul 2013 06:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 dT2J9XPfMX6F; Fri, 26 Jul 2013 06:42:58 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DFED921F8793; Fri, 26 Jul 2013 06:42:57 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q54so1852693wes.5 for ; Fri, 26 Jul 2013 06:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=th49Cr7NJWQ55YHFYkmT+pyoT5QPwLLqV+wzVVw8mIY=; b=Su75fsqClNA/bBWLrmlw7U3URsb+aJxi32n+3/x10k+fvDMn4sfVHcO30NlcSM5NyL gCq/20Fs/zNGAT+jhul64xSLp1FQBn9FO50H1DXuTdv/Wt1Kiwq+nTi2yCL4d36R6tQa REyaAErT9FpHhSY+e/iE5KigIdHlef5qvibdjos3wiVjycoSrxY6WXRDJIV+yoX31HaF gGBK2crKRNhIyP06ND0ZaTd6dccjgdU1XywBVpMub26tmw8KMEz1YX7p41Wq97NoYVDW kpBr5X6gjN15CKX8xGehgXEMmxMAh03YGOalMfiIL657YPBWMf3YqP5uSCcF9kpux/fO y5EQ== MIME-Version: 1.0 X-Received: by 10.180.211.171 with SMTP id nd11mr5796542wic.17.1374846177031; Fri, 26 Jul 2013 06:42:57 -0700 (PDT) Received: by 10.216.248.194 with HTTP; Fri, 26 Jul 2013 06:42:56 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> Date: Fri, 26 Jul 2013 09:42:56 -0400 Message-ID: From: Kaiduan Xie To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11c3850000c0fa04e26a52cb Cc: "rtcweb@ietf.org" , behave Subject: Re: [rtcweb] [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 13:42:59 -0000 --001a11c3850000c0fa04e26a52cb Content-Type: text/plain; charset=ISO-8859-1 Justin, I recommend you to put a note into the draft to state the following two points, 1) The user name and password are generated by the web server instead of the TURN server. 2) There is no communication channel required between web server and TURN server. >From the title (TURN Server REST API) and the text, it is easy to misunderstand that TURN server processes the HTTP POST request. Thanks, /Kaiduan On Wed, Jul 24, 2013 at 10:06 AM, Oleg Moskalenko wrote: > Thank you for the new link. > > I checked the new version of the draft and I personally see no problem in > the text. There is no proprietary software requirements in the draft. It > simply defines the logic how the TURN server and web server can organize > the temporary password generation, without imposing any proprietary > requirements and specs on the software. It is mentioning a possible > communication channel between web server and TURN server without defining > any specs and as it is written that channel is not required. As it is > written, I do not think that it has to be separated into two pieces - it is > a single solid logical functionality definition. > > Thanks > Oleg > > > On Wed, Jul 24, 2013 at 1:46 AM, Rajmohan Banavi > wrote: > >> This is the draft (BEHAVE WG) I am referring to - >> http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 >> >> >>> This is not the case. It is not the TURN server who generates the >>> credentials. The web server must generate the temporary password, and to be >>> able to do that the web server must have the shared secret - the same as >>> TURN server has. How they share the same shared secret I'd leave outside >>> the proposed specs. >>> >>> OK fine. >> >> >>> It is rather clear - the web server takes the shared secret and it >>> generates the temporary password for long-term TURN credentials. The TURN >>> server can reproduce that generation process and obtain the same temporary >>> password - because the TURN server knows the same shared secret as the web >>> server. >>> >> >> OK fine. >> >> Thanks, >> Rajmohan >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c3850000c0fa04e26a52cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Justin,

I recommend you to put a = note into the draft to state the following two points,

1= ) The user name and password are generated by the web server instead of the= TURN server.

2) There is no communication channel required between w= eb server and TURN server.

From the title (TURN Se= rver REST API) and the text, it is easy to misunderstand that TURN server p= rocesses the HTTP POST request.

Thanks,

/Kaiduan<= br>
On Wed, Jul 24, 2013 at 10:06 AM, Oleg Mo= skalenko <mom040267@gmail.com> wrote:
Thank you for the= new link.

I checked the new version of the draft and I personally = see no problem in the text. There is no proprietary software requirements i= n the draft. It simply defines the logic how the TURN server and web server= can organize the temporary password generation, without imposing any propr= ietary requirements and specs on the software. It is mentioning a possible = communication channel between web server and TURN server without defining a= ny specs and as it is written that channel is not required. As it is writte= n, I do not think that it has to be separated into two pieces - it is a sin= gle solid logical functionality definition.

Thanks
<= /span>
Oleg
=


On Wed, Jul 24, 2013 at 1:46 AM, Rajmohan Banavi <rajmohanbanavi@gm= ail.com> wrote:
This is the draft (BEHAVE WG) I am referri= ng to -=A0http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00=


This is not the case. It is not the TURN server who generat= es the credentials. The web server must generate the temporary password, an= d to be able to do that the web server must have the shared secret - the sa= me as TURN server has. How they share the same shared secret I'd leave = outside the proposed specs.

OK fin= e.
=A0
It is rather clear - the web server takes the shared secret and it generat= es the temporary password for long-term TURN credentials. The TURN server c= an reproduce that generation process and obtain the same temporary password= - because the TURN server knows the same shared secret as the web server.<= br>

<= /div>
OK fine.

Th= anks,
Rajmohan


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


--001a11c3850000c0fa04e26a52cb-- From fluffy@iii.ca Fri Jul 26 11:10:06 2013 Return-Path: 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 4DE8E21F99CE for ; Fri, 26 Jul 2013 11:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 V-05pj7flr-w for ; Fri, 26 Jul 2013 11:10:01 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 586E111E80F6 for ; Fri, 26 Jul 2013 11:10:01 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 961D822E200; Fri, 26 Jul 2013 14:09:54 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Fri, 26 Jul 2013 12:09:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> To: Bernard Aboba X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 18:10:06 -0000 Yah, I get your point. I will try and find a way to better represent = this on the slides.=20 On Jul 5, 2013, at 3:25 PM, Bernard Aboba = wrote: > I think you need to take dependencies into account. There are = several reasons for this:=20 >=20 > a. Until you've gone through the dependency graph for the items, = the full list of documents that need to be tracked isn't known.=20 > b. Estimates of completion are dependent on the progress of = normative dependencies (e.g. they can't be published until the = dependencies are resolved).=20 >=20 > As an example, draft-ietf-rtcweb-overview (which is listed as 80 = percent complete) has normative references to the following drafts:=20 >=20 > [I-D.ietf-mmusic-sctp-sdp] 70 > [I-D.ietf-rtcweb-audio] 50 > [I-D.ietf-rtcweb-data-channel] 70 > [I-D.ietf-rtcweb-jsep] 50 > [I-D.ietf-rtcweb-rtp-usage] 40 > [I-D.ietf-rtcweb-security] 80 > [I-D.ietf-rtcweb-security-arch] 80 > [I-D.nandakumar-rtcweb-stun-uri] 80 > [I-D.tuexen-tsvwg-sctp-dtls-encaps] 70 > =20 > Since draft-ietf-rtcweb-overview is dependent on a document (rtp = usage) which only has an estimate of 40 percent done) I'd say that the = estimate is probably closer to 40 than 80.=20 >=20 >=20 > > From: fluffy@iii.ca > > Date: Thu, 4 Jul 2013 17:47:20 -0700 > > To: rtcweb@ietf.org > > Subject: [rtcweb] Question about the status of various drafts > >=20 > >=20 > > As part of putting together some chair slides for Berlin, I'm trying = to get a very rough idea of where things are. I'd like to get folks = input on what percent done various drafts are where Done is a published = RFC.=20 > >=20 > > This is nearly impossible to do at any level of accuracy but I do = want to get a vague idea. I took a very rough stab below just to have a = starting point to get the conversation going. I'm sure my numbers are = mostly wrong but I have tried to ask a few people and sort of take the = central cluster of the guess. If you think I am way out, please provide = some feedback of what you think the number actually is. > >=20 > > I'm happy to get feedback on specific drafts or feedback of the form = they are all too low or too high. I do encourage people to realistically = look at the data tracker to see how long other drafts have taken for = each stage to get a baseline instead of just going with their gut feel.=20= > >=20 > > Thanks, Cullen > >=20 > > PS - if you are an author and look at the number next to your draft = and think it is way off, please please, say something.=20 > >=20 > >=20 > >=20 > > draft-ietf-rtcweb-overview 80 > > draft-ietf-rtcweb-use-cases-and-requirements 70 > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html 70 > > draft-burnett-rtcweb-constraints-registry 80 > > http://dev.w3.org/2011/webrtc/editor/webrtc.html 50 > > draft-nandakumar-rtcweb-stun-uri 80 > > draft-petithuguenin-behave-turn-uris 80 > > draft-ietf-rtcweb-security 80 > > draft-ietf-rtcweb-security-arch 80 > > draft-muthu-behave-consent-freshness-02 50 > > draft-ietf-rtcweb-data-channel 70 > > draft-ietf-mmusic-sctp-sdp 70 > > draft-jesup-rtcweb-data-protocol 50 > > draft-ietf-tsvwg-sctp-dtls-encaps 70 > > draft-ietf-rtcweb-rtp-usage 40 > > draft-ietf-avtcore-6222bis 80 > > draft-ietf-avtcore-avp-codecs 80 > > draft-ietf-avtcore-srtp-encrypted-header-ext 80 > > draft-ietf-avtext-multiple-clock-rates 70 > > draft-lennox-rtcweb-rtp-media-type-mux 80 > > draft-ietf-avtcore-rtp-circuit-breakers 70 > > draft-ietf-avtcore-multi-media-rtp-session 70 > > draft-lennox-avtcore-rtp-multi-stream 70 > > draft-ietf-rtcweb-jsep 50 > > draft-ietf-mmusic-msid 70 > > draft-rescorla-mmusic-ice-trickle 25 > > draft-ietf-mmusic-sdp-bundle-negotiation 50 > > draft-nandakumar-mmusic-sdp-mux-attributes 25 > > draft-dhesikan-tsvwg-rtcweb-qos 10 or 90 > > draft-ietf-rtcweb-audio 50 > > draft-ietf-payload-rtp-opus 90 > > draft-ietf-payload-vp8-08 95 > >=20 > >=20 > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Fri Jul 26 11:56:45 2013 Return-Path: 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 D8B9611E812B for ; Fri, 26 Jul 2013 11:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 YxQ+ctG7zmVk for ; Fri, 26 Jul 2013 11:56:41 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id ADC3011E80F6 for ; Fri, 26 Jul 2013 11:56:40 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-63-51f2c667e6d6 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9C.B1.00725.766C2F15; Fri, 26 Jul 2013 20:56:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Fri, 26 Jul 2013 20:56:39 +0200 From: Christer Holmberg To: Cullen Jennings , Bernard Aboba Thread-Topic: [rtcweb] Question about the status of various drafts Thread-Index: AQHOeRk/xEWRvnU2UUyUoui5CoC7yJlWeJoAgCDKU4CAAC6YBA== Date: Fri, 26 Jul 2013 18:56:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C40AE21@ESESSMB209.ericsson.se> References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C40AE21ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrW76sU+BBk8e6FrsX3KZ2eLD+h+M Fmv/tbM7MHs87jnD5rFkyU8mj8vnPzIGMEdx2aSk5mSWpRbp2yVwZcx+9Jy9YFNGxdl5Wxgb GF9EdDFyckgImEhsm93MAmGLSVy4t56ti5GLQ0jgMKNE55K9rBDOEkaJZx//sHcxcnCwCVhI dP/TBmkQEfCTWNrxhR3EZhZQlTh/6BwjiC0s4CjR3HGADaLGSWLF/CVMMPbEiefB4ixA9Vcu vATr5RXwlTjWuhZq13RGiYbrf8AaOAWsJL6+6QFrYAS67vupNUwQy8Qlbj2ZzwRxtYDEkj3n mSFsUYmXj/+xQtTkS3yc+IgZYoGgxMmZT1gmMIrMQtI+C0nZLCRlEHEdiQW7P7FB2NoSyxa+ Zoaxzxx4zIQsvoCRfRUje25iZk56ueEmRmBEHdzyW3cH46lzIocYpTlYlMR5N+mdCRQSSE8s Sc1OTS1ILYovKs1JLT7EyMTBKdXA2FS8U6ZRfpdtVdaMwoXtpmanN2W5OJWvfhsmv6dLKMAx SETEYt1rz30NrBJi+qeYrlxektzI9zfmsFPzR/sPJX3L9/eUGV+pPGDce+uYu+HuVx8PJc3J Ott93/7mT8uW3VqvLix2Nt8Xtiwob7vvl+p9rX+DBC80/FmwKj9X98H+nir/Mn01JZbijERD Leai4kQA8mo+U3YCAAA= Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 18:56:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C40AE21ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Cullen, I may missed something, but it seems a little strange to me when individual= drafts, that haven't even been adopted yet, are indicated as 70-80% comple= te... Some drafts have also expired. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Cullen Jennings [fluffy@iii.ca] To: Bernard Aboba [bernard_aboba@hotmail.com] CC: rtcweb@ietf.org [rtcweb@ietf.org] Subject: Re: [rtcweb] Question about the status of various drafts Yah, I get your point. I will try and find a way to better represent this o= n the slides. On Jul 5, 2013, at 3:25 PM, Bernard Aboba wrote= : > I think you need to take dependencies into account. There are several r= easons for this: > > a. Until you've gone through the dependency graph for the items, the f= ull list of documents that need to be tracked isn't known. > b. Estimates of completion are dependent on the progress of normative = dependencies (e.g. they can't be published until the dependencies are resol= ved). > > As an example, draft-ietf-rtcweb-overview (which is listed as 80 percent= complete) has normative references to the following drafts: > > [I-D.ietf-mmusic-sctp-sdp] 70 > [I-D.ietf-rtcweb-audio] 50 > [I-D.ietf-rtcweb-data-channel] 70 > [I-D.ietf-rtcweb-jsep] 50 > [I-D.ietf-rtcweb-rtp-usage] 40 > [I-D.ietf-rtcweb-security] 80 > [I-D.ietf-rtcweb-security-arch] 80 > [I-D.nandakumar-rtcweb-stun-uri] 80 > [I-D.tuexen-tsvwg-sctp-dtls-encaps] 70 > > Since draft-ietf-rtcweb-overview is dependent on a document (rtp usage) w= hich only has an estimate of 40 percent done) I'd say that the estimate is = probably closer to 40 than 80. > > > > From: fluffy@iii.ca > > Date: Thu, 4 Jul 2013 17:47:20 -0700 > > To: rtcweb@ietf.org > > Subject: [rtcweb] Question about the status of various drafts > > > > > > As part of putting together some chair slides for Berlin, I'm trying to= get a very rough idea of where things are. I'd like to get folks input on = what percent done various drafts are where Done is a published RFC. > > > > This is nearly impossible to do at any level of accuracy but I do want = to get a vague idea. I took a very rough stab below just to have a starting= point to get the conversation going. I'm sure my numbers are mostly wrong = but I have tried to ask a few people and sort of take the central cluster o= f the guess. If you think I am way out, please provide some feedback of wha= t you think the number actually is. > > > > I'm happy to get feedback on specific drafts or feedback of the form th= ey are all too low or too high. I do encourage people to realistically look= at the data tracker to see how long other drafts have taken for each stage= to get a baseline instead of just going with their gut feel. > > > > Thanks, Cullen > > > > PS - if you are an author and look at the number next to your draft and= think it is way off, please please, say something. > > > > > > > > draft-ietf-rtcweb-overview 80 > > draft-ietf-rtcweb-use-cases-and-requirements 70 > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html 70 > > draft-burnett-rtcweb-constraints-registry 80 > > http://dev.w3.org/2011/webrtc/editor/webrtc.html 50 > > draft-nandakumar-rtcweb-stun-uri 80 > > draft-petithuguenin-behave-turn-uris 80 > > draft-ietf-rtcweb-security 80 > > draft-ietf-rtcweb-security-arch 80 > > draft-muthu-behave-consent-freshness-02 50 > > draft-ietf-rtcweb-data-channel 70 > > draft-ietf-mmusic-sctp-sdp 70 > > draft-jesup-rtcweb-data-protocol 50 > > draft-ietf-tsvwg-sctp-dtls-encaps 70 > > draft-ietf-rtcweb-rtp-usage 40 > > draft-ietf-avtcore-6222bis 80 > > draft-ietf-avtcore-avp-codecs 80 > > draft-ietf-avtcore-srtp-encrypted-header-ext 80 > > draft-ietf-avtext-multiple-clock-rates 70 > > draft-lennox-rtcweb-rtp-media-type-mux 80 > > draft-ietf-avtcore-rtp-circuit-breakers 70 > > draft-ietf-avtcore-multi-media-rtp-session 70 > > draft-lennox-avtcore-rtp-multi-stream 70 > > draft-ietf-rtcweb-jsep 50 > > draft-ietf-mmusic-msid 70 > > draft-rescorla-mmusic-ice-trickle 25 > > draft-ietf-mmusic-sdp-bundle-negotiation 50 > > draft-nandakumar-mmusic-sdp-mux-attributes 25 > > draft-dhesikan-tsvwg-rtcweb-qos 10 or 90 > > draft-ietf-rtcweb-audio 50 > > draft-ietf-payload-rtp-opus 90 > > draft-ietf-payload-vp8-08 95 > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1C40AE21ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Cullen,
 
I may missed something, but it seems a little s= trange to me when individual drafts, that haven't even been adopted yet, ar= e indicated as 70-80% complete...
 
Some drafts have also expired.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Cullen Jennings [fluffy@iii.ca]
To: Bernard Aboba [bernard_aboba@hotmail.com]
CC: rtcweb@ietf.org [rtcweb@ietf.org]
Subject: Re: [rtcweb] Question about the status of various drafts

Yah, I get your point. I will try and find a way to better represent this o= n the slides.


On Jul 5, 2013, at 3:25 PM, Bernard Aboba <bernard_aboba@hotmail.com>= wrote:

> I think you need to take dependencies into account.   There = are several reasons for this:
>
>    a. Until you've gone through the dependency graph fo= r the items, the full list of documents that need to be tracked isn't known= .
>    b. Estimates of completion are dependent on the prog= ress of normative dependencies (e.g. they can't be published until the depe= ndencies are resolved).
>
> As an example,  draft-ietf-rtcweb-overview (which is listed as 80= percent complete) has normative references to the following drafts:
>
>    [I-D.ietf-mmusic-sctp-sdp] 70
>    [I-D.ietf-rtcweb-audio] 50
>    [I-D.ietf-rtcweb-data-channel] 70
>    [I-D.ietf-rtcweb-jsep] 50
>    [I-D.ietf-rtcweb-rtp-usage] 40
>    [I-D.ietf-rtcweb-security] 80
>    [I-D.ietf-rtcweb-security-arch] 80
>    [I-D.nandakumar-rtcweb-stun-uri] 80
>    [I-D.tuexen-tsvwg-sctp-dtls-encaps] 70
>            = ;
> Since draft-ietf-rtcweb-overview is dependent on a document (rtp usage= ) which only has an estimate of 40 percent done) I'd say that the estimate = is probably closer to 40 than 80.
>
>
> > From: fluffy@iii.ca
> > Date: Thu, 4 Jul 2013 17:47:20 -0700
> > To: rtcweb@ietf.org
> > Subject: [rtcweb] Question about the status of various drafts
> >
> >
> > As part of putting together some chair slides for Berlin, I'm try= ing to get a very rough idea of where things are. I'd like to get folks inp= ut on what percent done various drafts are where Done is a published RFC.
> >
> > This is nearly impossible to do at any level of accuracy but I do= want to get a vague idea. I took a very rough stab below just to have a st= arting point to get the conversation going. I'm sure my numbers are mostly = wrong but I have tried to ask a few people and sort of take the central cluster of the guess. If you think I am way o= ut, please provide some feedback of what you think the number actually is.<= br> > >
> > I'm happy to get feedback on specific drafts or feedback of the f= orm they are all too low or too high. I do encourage people to realisticall= y look at the data tracker to see how long other drafts have taken for each= stage to get a baseline instead of just going with their gut feel.
> >
> > Thanks, Cullen
> >
> > PS - if you are an author and look at the number next to your dra= ft and think it is way off, please please, say something.
> >
> >
> >
> > draft-ietf-rtcweb-overview   80
> > draft-ietf-rtcweb-use-cases-and-requirements   &nb= sp;    70
> > http://dev.w3.org/2011/webrtc/editor/getusermedia.html  &nb= sp;    70
> > draft-burnett-rtcweb-constraints-registry    80 > > http= ://dev.w3.org/2011/webrtc/editor/webrtc.html     50=
> > draft-nandakumar-rtcweb-stun-uri     80
> > draft-petithuguenin-behave-turn-uris     = ;    80
> > draft-ietf-rtcweb-security   80
> > draft-ietf-rtcweb-security-arch      80<= br> > > draft-muthu-behave-consent-freshness-02 50
> > draft-ietf-rtcweb-data-channel      = ; 70
> > draft-ietf-mmusic-sctp-sdp   70
> > draft-jesup-rtcweb-data-protocol 50
> > draft-ietf-tsvwg-sctp-dtls-encaps    70
> > draft-ietf-rtcweb-rtp-usage  40
> > draft-ietf-avtcore-6222bis   80
> > draft-ietf-avtcore-avp-codecs      =   80
> > draft-ietf-avtcore-srtp-encrypted-header-ext   &nb= sp;    80
> > draft-ietf-avtext-multiple-clock-rates    &nb= sp;  70
> > draft-lennox-rtcweb-rtp-media-type-mux 80
> > draft-ietf-avtcore-rtp-circuit-breakers    &n= bsp; 70
> > draft-ietf-avtcore-multi-media-rtp-session 70
> > draft-lennox-avtcore-rtp-multi-stream    &nbs= p;   70
> > draft-ietf-rtcweb-jsep       50
> > draft-ietf-mmusic-msid       70
> > draft-rescorla-mmusic-ice-trickle    25
> > draft-ietf-mmusic-sdp-bundle-negotiation    50
> > draft-nandakumar-mmusic-sdp-mux-attributes  25
> > draft-dhesikan-tsvwg-rtcweb-qos      10 = or 90
> > draft-ietf-rtcweb-audio      50
> > draft-ietf-payload-rtp-opus  90
> > draft-ietf-payload-vp8-08    95
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
 --_000_7594FB04B1934943A5C02806D1A2204B1C40AE21ESESSMB209erics_-- From keith.drage@alcatel-lucent.com Fri Jul 26 12:35:34 2013 Return-Path: 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 9DBB111E813A for ; Fri, 26 Jul 2013 12:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 jRF18OkxO9XR for ; Fri, 26 Jul 2013 12:35:29 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7649D11E812D for ; Fri, 26 Jul 2013 12:35:29 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6QJZK9U003721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Jul 2013 14:35:22 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6QJZIIL003584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 21:35:18 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 26 Jul 2013 21:35:18 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Cullen Jennings , Bernard Aboba Thread-Topic: [rtcweb] Question about the status of various drafts Thread-Index: AQHOiithoT7qFE1n6kuVPv9JHJpg3Jl3LdkAgAApDAA= Date: Fri, 26 Jul 2013 19:35:18 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0746F0@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> , <7594FB04B1934943A5C02806D1A2204B1C40AE21@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C40AE21@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0746F0FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 19:35:34 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B0746F0FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd missed that. By definition an author draft has 0% completion because no working group ha= s reached consensus on any of the text. Looks like you (or other RTCWEB chairs) need to start talking to other WG c= hairs about initiating adoption of drafts as WG items. I don't at the momen= t see anything in the list that should avoid going the WG route. Regards Keith ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 26 July 2013 19:57 To: Cullen Jennings; Bernard Aboba Cc: rtcweb_ietf.org Subject: Re: [rtcweb] Question about the status of various drafts Hi Cullen, I may missed something, but it seems a little strange to me when individual= drafts, that haven't even been adopted yet, are indicated as 70-80% comple= te... Some drafts have also expired. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Cullen Jennings [fluffy@iii.ca] To: Bernard Aboba [bernard_aboba@hotmail.com] CC: rtcweb@ietf.org [rtcweb@ietf.org] Subject: Re: [rtcweb] Question about the status of various drafts Yah, I get your point. I will try and find a way to better represent this o= n the slides. On Jul 5, 2013, at 3:25 PM, Bernard Aboba wrote= : > I think you need to take dependencies into account. There are several r= easons for this: > > a. Until you've gone through the dependency graph for the items, the f= ull list of documents that need to be tracked isn't known. > b. Estimates of completion are dependent on the progress of normative = dependencies (e.g. they can't be published until the dependencies are resol= ved). > > As an example, draft-ietf-rtcweb-overview (which is listed as 80 percent= complete) has normative references to the following drafts: > > [I-D.ietf-mmusic-sctp-sdp] 70 > [I-D.ietf-rtcweb-audio] 50 > [I-D.ietf-rtcweb-data-channel] 70 > [I-D.ietf-rtcweb-jsep] 50 > [I-D.ietf-rtcweb-rtp-usage] 40 > [I-D.ietf-rtcweb-security] 80 > [I-D.ietf-rtcweb-security-arch] 80 > [I-D.nandakumar-rtcweb-stun-uri] 80 > [I-D.tuexen-tsvwg-sctp-dtls-encaps] 70 > > Since draft-ietf-rtcweb-overview is dependent on a document (rtp usage) w= hich only has an estimate of 40 percent done) I'd say that the estimate is = probably closer to 40 than 80. > > > > From: fluffy@iii.ca > > Date: Thu, 4 Jul 2013 17:47:20 -0700 > > To: rtcweb@ietf.org > > Subject: [rtcweb] Question about the status of various drafts > > > > > > As part of putting together some chair slides for Berlin, I'm trying to= get a very rough idea of where things are. I'd like to get folks input on = what percent done various drafts are where Done is a published RFC. > > > > This is nearly impossible to do at any level of accuracy but I do want = to get a vague idea. I took a very rough stab below just to have a starting= point to get the conversation going. I'm sure my numbers are mostly wrong = but I have tried to ask a few people and sort of take the central cluster o= f the guess. If you think I am way out, please provide some feedback of wha= t you think the number actually is. > > > > I'm happy to get feedback on specific drafts or feedback of the form th= ey are all too low or too high. I do encourage people to realistically look= at the data tracker to see how long other drafts have taken for each stage= to get a baseline instead of just going with their gut feel. > > > > Thanks, Cullen > > > > PS - if you are an author and look at the number next to your draft and= think it is way off, please please, say something. > > > > > > > > draft-ietf-rtcweb-overview 80 > > draft-ietf-rtcweb-use-cases-and-requirements 70 > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html 70 > > draft-burnett-rtcweb-constraints-registry 80 > > http://dev.w3.org/2011/webrtc/editor/webrtc.html 50 > > draft-nandakumar-rtcweb-stun-uri 80 > > draft-petithuguenin-behave-turn-uris 80 > > draft-ietf-rtcweb-security 80 > > draft-ietf-rtcweb-security-arch 80 > > draft-muthu-behave-consent-freshness-02 50 > > draft-ietf-rtcweb-data-channel 70 > > draft-ietf-mmusic-sctp-sdp 70 > > draft-jesup-rtcweb-data-protocol 50 > > draft-ietf-tsvwg-sctp-dtls-encaps 70 > > draft-ietf-rtcweb-rtp-usage 40 > > draft-ietf-avtcore-6222bis 80 > > draft-ietf-avtcore-avp-codecs 80 > > draft-ietf-avtcore-srtp-encrypted-header-ext 80 > > draft-ietf-avtext-multiple-clock-rates 70 > > draft-lennox-rtcweb-rtp-media-type-mux 80 > > draft-ietf-avtcore-rtp-circuit-breakers 70 > > draft-ietf-avtcore-multi-media-rtp-session 70 > > draft-lennox-avtcore-rtp-multi-stream 70 > > draft-ietf-rtcweb-jsep 50 > > draft-ietf-mmusic-msid 70 > > draft-rescorla-mmusic-ice-trickle 25 > > draft-ietf-mmusic-sdp-bundle-negotiation 50 > > draft-nandakumar-mmusic-sdp-mux-attributes 25 > > draft-dhesikan-tsvwg-rtcweb-qos 10 or 90 > > draft-ietf-rtcweb-audio 50 > > draft-ietf-payload-rtp-opus 90 > > draft-ietf-payload-vp8-08 95 > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_949EF20990823C4C85C18D59AA11AD8B0746F0FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d missed that.

 

By definition an author draft has 0% c= ompletion because no working group has reached consensus on any of the text= .

 

Looks like you (or other RTCWEB chairs= ) need to start talking to other WG chairs about initiating adoption of dra= fts as WG items. I don’t at the moment see anything in the list that should avoid going the WG rout= e.

 

Regards

 

Keith

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Be= half Of Christer Holmberg
Sent: 26 July 2013 19:57
To: Cullen Jennings; Bernard= Aboba
Cc: rtcweb_ietf.org
Subject: Re: [rtcweb] Questi= on about the status of various drafts

 

Hi Cullen,

 <= /o:p>

I may missed= something, but it seems a little strange to me when individual drafts, tha= t haven't even been adopted yet, are indicated as 70-80% complete...

 <= /o:p>

Some drafts = have also expired.

 <= /o:p>

Regards,

 <= /o:p>

Christer

 <= /o:p>



Sent from Windows<= /span> using Tou= chDown<= span style=3D"font-size:11.0pt;font-family:Calibri; color:black"> (www.nitrodesk.com)


-----Original Message-----
From: Cullen Jennings [fluff= y@iii.ca]
To: Bernard Aboba [bernard_a= boba@hotmail.com]
CC: rtcweb@ietf.org [rtcweb@= ietf.org]
Subject: Re: [rtcweb] Questi= on about the status of various drafts


Yah, I get your point. I will try and find a way to better represent this o= n the slides.


On Jul 5, 2013, at 3:25 PM, Bernard Aboba <bernard_aboba@hotmail.com>= wrote:

> I think you need to take dependencies into account.   There = are several reasons for this:
>
>    a. Until you've gone through the dependency graph fo= r the items, the full list of documents that need to be tracked isn't known= .
>    b. Estimates of completion are dependent on the prog= ress of normative dependencies (e.g. they can't be published until the depe= ndencies are resolved).
>
> As an example,  draft-ietf-rtcweb-overview (which is listed as 80= percent complete) has normative references to the following drafts:
>
>    [I-D.ietf-mmusic-sctp-sdp] 70
>    [I-D.ietf-rtcweb-audio] 50
>    [I-D.ietf-rtcweb-data-channel] 70
>    [I-D.ietf-rtcweb-jsep] 50
>    [I-D.ietf-rtcweb-rtp-usage] 40
>    [I-D.ietf-rtcweb-security] 80
>    [I-D.ietf-rtcweb-security-arch] 80
>    [I-D.nandakumar-rtcweb-stun-uri] 80
>    [I-D.tuexen-tsvwg-sctp-dtls-encaps] 70
>            = ;
> Since draft-ietf-rtcweb-overview is dependent on a document (rtp usage= ) which only has an estimate of 40 percent done) I'd say that the estimate = is probably closer to 40 than 80.
>
>
> > From: fluffy@iii.ca
> > Date: Thu, 4 Jul 2013 17:47:20 -0700
> > To: rtcweb@ietf.org
> > Subject: [rtcweb] Question about the status of various drafts
> >
> >
> > As part of putting together some chair slides for Berlin, I'm trying t= o get a very rough idea of where things are. I'd like to get folks input on= what percent done various drafts are where Done is a published RFC.
> >
> > This is nearly impossible to do at any level of accuracy but I do= want to get a vague idea. I took a very rough stab below just to have a st= arting point to get the conversation going. I'm sure my numbers are mostly = wrong but I have tried to ask a few people and sort of take the central cluster of the guess. If you think I am way o= ut, please provide some feedback of what you think the number actually is.<= br> > >
> > I'm happy to get feedback on specific drafts or feedback of the f= orm they are all too low or too high. I do encourage people to realisticall= y look at the data tracker to see how long other drafts have taken for each= stage to get a baseline instead of just going with their gut feel.
> >
> > Thanks, Cullen
> >
> > PS - if you are an author and look at the number next to your dra= ft and think it is way off, please please, say something.
> >
> >
> >
> > draft-ietf-rtcweb-overview   80
> > draft-ietf-rtcweb-use-cases-and-requirements   &nb= sp;    70
> > http://dev.w3.org/2011/webrtc/editor/getusermedia.html  &nb= sp;    70
> > draft-burnett-rtcweb-constraints-registry    80 > > http= ://dev.w3.org/2011/webrtc/editor/webrtc.html     50=
> > draft-nandakumar-rtcweb-stun-uri     80
> > draft-petithuguenin-behave-turn-uris     = ;    80
> > draft-ietf-rtcweb-security   80
> > draft-ietf-rtcweb-security-arch      80<= br> > > draft-muthu-behave-consent-freshness-02 50
> > draft-ietf-rtcweb-data-channel      = ; 70
> > draft-ietf-mmusic-sctp-sdp   70
> > draft-jesup-rtcweb-data-protocol 50
> > draft-ietf-tsvwg-sctp-dtls-encaps    70
> > draft-ietf-rtcweb-rtp-usage  40
> > draft-ietf-avtcore-6222bis   80
> > draft-ietf-avtcore-avp-codecs      =   80
> > draft-ietf-avtcore-srtp-encrypted-header-ext   &nb= sp;    80
> > draft-ietf-avtext-multiple-clock-rates    &nb= sp;  70
> > draft-lennox-rtcweb-rtp-media-type-mux 80
> > draft-ietf-avtcore-rtp-circuit-breakers    &n= bsp; 70
> > draft-ietf-avtcore-multi-media-rtp-session 70
> > draft-lennox-avtcore-rtp-multi-stream    &nbs= p;   70
> > draft-ietf-rtcweb-jsep       50
> > draft-ietf-mmusic-msid       70
> > draft-rescorla-mmusic-ice-trickle    25
> > draft-ietf-mmusic-sdp-bundle-negotiation    50
> > draft-nandakumar-mmusic-sdp-mux-attributes  25
> > draft-dhesikan-tsvwg-rtcweb-qos      10 = or 90
> > draft-ietf-rtcweb-audio      50
> > draft-ietf-payload-rtp-opus  90
> > draft-ietf-payload-vp8-08    95
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb

--_000_949EF20990823C4C85C18D59AA11AD8B0746F0FR712WXCHMBA11zeu_-- From fluffy@iii.ca Fri Jul 26 12:59:00 2013 Return-Path: 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 09FBC11E80FB for ; Fri, 26 Jul 2013 12:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 lsNlBQC8AEQu for ; Fri, 26 Jul 2013 12:58:55 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD4A11E8127 for ; Fri, 26 Jul 2013 12:58:54 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 68C3D22E1FA; Fri, 26 Jul 2013 15:58:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C40AE21@ESESSMB209.ericsson.se> Date: Fri, 26 Jul 2013 13:58:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <572C6849-5315-40CB-A3E2-D59AD9BDC4F7@iii.ca> References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> , <7594FB04B1934943A5C02806D1A2204B1C40AE21@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) Cc: "rtcweb_ietf.org" Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 19:59:00 -0000 I'm in the process of updating it it all - I'll try and make reasonable = estimates. Note some of the individual drafts are planned to be AD = sponsored.=20 On Jul 26, 2013, at 12:56 PM, Christer Holmberg = wrote: > Hi Cullen, > =20 > I may missed something, but it seems a little strange to me when = individual drafts, that haven't even been adopted yet, are indicated as = 70-80% complete... > =20 > Some drafts have also expired. > =20 > Regards, > =20 > Christer > =20 >=20 >=20 > Sent from Windows using TouchDown (www.nitrodesk.com) >=20 > -----Original Message----- > From: Cullen Jennings [fluffy@iii.ca] > To: Bernard Aboba [bernard_aboba@hotmail.com] > CC: rtcweb@ietf.org [rtcweb@ietf.org] > Subject: Re: [rtcweb] Question about the status of various drafts >=20 > Yah, I get your point. I will try and find a way to better represent = this on the slides.=20 >=20 >=20 > On Jul 5, 2013, at 3:25 PM, Bernard Aboba = wrote: >=20 > > I think you need to take dependencies into account. There are = several reasons for this:=20 > >=20 > > a. Until you've gone through the dependency graph for the items, = the full list of documents that need to be tracked isn't known.=20 > > b. Estimates of completion are dependent on the progress of = normative dependencies (e.g. they can't be published until the = dependencies are resolved).=20 > >=20 > > As an example, draft-ietf-rtcweb-overview (which is listed as 80 = percent complete) has normative references to the following drafts:=20 > >=20 > > [I-D.ietf-mmusic-sctp-sdp] 70 > > [I-D.ietf-rtcweb-audio] 50 > > [I-D.ietf-rtcweb-data-channel] 70 > > [I-D.ietf-rtcweb-jsep] 50 > > [I-D.ietf-rtcweb-rtp-usage] 40 > > [I-D.ietf-rtcweb-security] 80 > > [I-D.ietf-rtcweb-security-arch] 80 > > [I-D.nandakumar-rtcweb-stun-uri] 80 > > [I-D.tuexen-tsvwg-sctp-dtls-encaps] 70 > > =20 > > Since draft-ietf-rtcweb-overview is dependent on a document (rtp = usage) which only has an estimate of 40 percent done) I'd say that the = estimate is probably closer to 40 than 80.=20 > >=20 > >=20 > > > From: fluffy@iii.ca > > > Date: Thu, 4 Jul 2013 17:47:20 -0700 > > > To: rtcweb@ietf.org > > > Subject: [rtcweb] Question about the status of various drafts > > >=20 > > >=20 > > > As part of putting together some chair slides for Berlin, I'm = trying to get a very rough idea of where things are. I'd like to get = folks input on what percent done various drafts are where Done is a = published RFC.=20 > > >=20 > > > This is nearly impossible to do at any level of accuracy but I do = want to get a vague idea. I took a very rough stab below just to have a = starting point to get the conversation going. I'm sure my numbers are = mostly wrong but I have tried to ask a few people and sort of take the = central cluster of the guess. If you think I am way out, please provide = some feedback of what you think the number actually is. > > >=20 > > > I'm happy to get feedback on specific drafts or feedback of the = form they are all too low or too high. I do encourage people to = realistically look at the data tracker to see how long other drafts have = taken for each stage to get a baseline instead of just going with their = gut feel.=20 > > >=20 > > > Thanks, Cullen > > >=20 > > > PS - if you are an author and look at the number next to your = draft and think it is way off, please please, say something.=20 > > >=20 > > >=20 > > >=20 > > > draft-ietf-rtcweb-overview 80 > > > draft-ietf-rtcweb-use-cases-and-requirements 70 > > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html 70 > > > draft-burnett-rtcweb-constraints-registry 80 > > > http://dev.w3.org/2011/webrtc/editor/webrtc.html 50 > > > draft-nandakumar-rtcweb-stun-uri 80 > > > draft-petithuguenin-behave-turn-uris 80 > > > draft-ietf-rtcweb-security 80 > > > draft-ietf-rtcweb-security-arch 80 > > > draft-muthu-behave-consent-freshness-02 50 > > > draft-ietf-rtcweb-data-channel 70 > > > draft-ietf-mmusic-sctp-sdp 70 > > > draft-jesup-rtcweb-data-protocol 50 > > > draft-ietf-tsvwg-sctp-dtls-encaps 70 > > > draft-ietf-rtcweb-rtp-usage 40 > > > draft-ietf-avtcore-6222bis 80 > > > draft-ietf-avtcore-avp-codecs 80 > > > draft-ietf-avtcore-srtp-encrypted-header-ext 80 > > > draft-ietf-avtext-multiple-clock-rates 70 > > > draft-lennox-rtcweb-rtp-media-type-mux 80 > > > draft-ietf-avtcore-rtp-circuit-breakers 70 > > > draft-ietf-avtcore-multi-media-rtp-session 70 > > > draft-lennox-avtcore-rtp-multi-stream 70 > > > draft-ietf-rtcweb-jsep 50 > > > draft-ietf-mmusic-msid 70 > > > draft-rescorla-mmusic-ice-trickle 25 > > > draft-ietf-mmusic-sdp-bundle-negotiation 50 > > > draft-nandakumar-mmusic-sdp-mux-attributes 25 > > > draft-dhesikan-tsvwg-rtcweb-qos 10 or 90 > > > draft-ietf-rtcweb-audio 50 > > > draft-ietf-payload-rtp-opus 90 > > > draft-ietf-payload-vp8-08 95 > > >=20 > > >=20 > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Sat Jul 27 07:00:05 2013 Return-Path: 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 8404E21F8C3E for ; Sat, 27 Jul 2013 07:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 totu9ElHJOhL for ; Sat, 27 Jul 2013 07:00:00 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id BEE7521F8CDD for ; Sat, 27 Jul 2013 06:59:52 -0700 (PDT) Received: from dhcp-10-61-111-139.cisco.com (unknown [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7D7C050A84; Sat, 27 Jul 2013 09:59:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Cullen Jennings In-Reply-To: Date: Sat, 27 Jul 2013 15:59:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2BC3A8BA-C550-4889-A8B5-28D937A8EB42@iii.ca> References: To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] A compromise for SDES X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 14:00:05 -0000 I'm a bit confused about your proposal.=20 =46rom a RTCWeb WG point of view, it seems that the key question is what = are we suggesting that things that implement WebRTC (including browsers) = do? Are you proposing that SDES in browsers be optional, mandatory, or = not allowed? On Jul 13, 2013, at 11:07 AM, Hadriel Kaplan = wrote: > Howdy, > Someone's asked me to explain the compromise I plan on presenting in = Berlin now, so we have more time to argue over it or chew on it. The = reason I was going to wait is because I wanted to explain how I got to = the point of thinking such a compromise would make sense. So I'll try = to do that in this email, which will make this email long. Nothin' much = I can do about that. >=20 > Obviously this is all my personal opinion, not that of my employer, = and not a statement claiming to be objective fact, etc. >=20 > Background: > I think many people would agree that SDES has some benefits compared = to DTLS for those of us wishing to interface to the SIP world. Some of = those benefits are commercial/cost factors, some are more tangible like = reducing early media clipping. Whether you agree with such benefits or = not, so long as WebRTC could support SDES in a sufficiently-secure = manner, there'd be less concern over having it. Most of the arguments = against SDES have been directed at whether it could in fact be = "sufficiently secure". Personally I find most of the arguments against = it being secure enough to be essentially FUD, and/or also apply to = DTLS-SRTP. >=20 > On the flip-side, I think the commercial/cost factor for SDES is not a = strong cause, because I believe the market will bear whatever the extra = cost may be. (I wasn't sure of this 2 years ago when this all started, = but I'm fairly confident of it now) And I think having only DTLS-SRTP = as MTI would have a marketing benefit for WebRTC as a technology, which = I value highly. >=20 > Given those personal feelings, I didn't much care either way, so long = as a decision was made - although I still preferred having SDES to avoid = the early media clipping problem. So when I was going to present on = this topic back in the Vancouver meeting, my last slide basically said: = "If we support SDES and it turns out later we were wrong, we can always = rescind it". This was based on the notion that browsers get updated all = the time, especially for security issues. >=20 > But later it occurred to me that's actually the Achilles' heel of = supporting SDES in WebRTC, for those of us wanting to gateway this stuff = to SIP. Imagine if it turns out we were wrong, and some = expected-or-unexpected vulnerability is exploited against some large = WebRTC service provider, and makes the news/slashdot. Browser vendors = would instantly have new code removing SDES support, and browsers in = devices would be updated virtually overnight - some users may take a = long time to upgrade their specific browsers on their specific devices - = but many of them would do so within days. That would be untenable for a = WebRTC service provider. Even the smaller Enterprises take a long time = to upgrade code on their servers, so even for them changing their = gateways to suddenly support DTLS-SRTP would be unrealistic. Imagine = what it would be for larger providers, who might even have to deploy = more servers to handle the sudden additional overhead of DTLS-SRTP. = Meanwhile a growing perc > entage of their users can no longer use the service. That's bad mojo. >=20 > The things that a WebRTC-to-SIP service provider can control, and = arguably the much larger use-case for this stuff to begin with, are not = really true "browsers" anyway - they're web-based-framework device Apps, = provided by the service provider to begin with. I.e., the apps they = build using web application framework things like PhoneGap/Cordova, = Appcelerator Titanium, etc. I mean using a real Browser is nice for = ad-hoc stuff, like being able to click on a "talk to a rep" button on a = website, or a webex/meetecho type thing; but for real communication = "service", whether it be as a subscriber of a traditional carrier, or = Skype, or an employee of an Enterprise, or a call-center attendant, or = whatever - for those most people would never want to have to open a = browser just to receive/make calls. They'd give you an app to use = instead. >=20 > So it's the app use-case that would benefit the most from SDES, = especially for issues like media clipping. And the app use-case doesn't = have the security concerns nor concerns for unforeseen overnight = updates. >=20 > The Compromise: > So given that background, I was planning to propose that the security = doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a = statement that web-based application frameworks SHOULD also support = SDES. (with text about why and how, etc.) >=20 > I don't think this is too controversial, because web-based frameworks = are never beholden to following browser behavior anyway - they're used = to build a native application, and native applications have a very = different security/threat model in practice. They're written for a = specific purpose, and installed by users from known sources for that = known purpose. Technically, afaik, nothing we do in RTCWEB WG or W3C's = WEBRTC group have any requirements/mandates for native applications = anyway - an app maker would just ignore something they don't think = applies to them - but I think web-based frameworks do generally try to = follow W3C models for Javascript APIs, and will likely read the IETF = RFCs for the media-layer stuff too. So I think having this SHOULD = statement would be beneficial. >=20 > Or if the WG prefers, we could even write a separate doc on what a = web-based framework maker should consider supporting/not-supporting. (I = can imagine a few other things they might want to offer that a browser = can't) >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Sat Jul 27 07:27:44 2013 Return-Path: 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 7BBE321F9AA8 for ; Sat, 27 Jul 2013 07:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 YtsDCT3CTbzG for ; Sat, 27 Jul 2013 07:27:39 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5802521F99FB for ; Sat, 27 Jul 2013 07:27:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2658A39E17B for ; Sat, 27 Jul 2013 16:27:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU8vnTPNBeNM for ; Sat, 27 Jul 2013 16:27:36 +0200 (CEST) Received: from [10.0.0.79] (unknown [91.113.173.59]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1E98739E13F for ; Sat, 27 Jul 2013 16:27:36 +0200 (CEST) Message-ID: <51F3D8D7.10409@alvestrand.no> Date: Sat, 27 Jul 2013 16:27:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7A95191A-6488-435E-B491-FEF3A6AC342F@iii.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020804010305020801010101" Subject: Re: [rtcweb] Question about the status of various drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 14:27:44 -0000 This is a multi-part message in MIME format. --------------020804010305020801010101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/05/2013 11:25 PM, Bernard Aboba wrote: > I think you need to take dependencies into account. There are > several reasons for this: > > a. Until you've gone through the dependency graph for the items, > the full list of documents that need to be tracked isn't known. > b. Estimates of completion are dependent on the progress of > normative dependencies (e.g. they can't be published until the > dependencies are resolved). > > As an example, draft-ietf-rtcweb-overview (which is listed as 80 > percent complete) has normative references to the following drafts: > > [I-D.ietf-mmusic-sctp-sdp] 70 > [I-D.ietf-rtcweb-audio] 50 > [I-D.ietf-rtcweb-data-channel] 70 > [I-D.ietf-rtcweb-jsep] 50 > [I-D.ietf-rtcweb-rtp-usage] 40 > [I-D.ietf-rtcweb-security] 80 > [I-D.ietf-rtcweb-security-arch] 80 > [I-D.nandakumar-rtcweb-stun-uri] 80 > [I-D.tuexen-tsvwg-sctp-dtls-encaps] 70 > > Since draft-ietf-rtcweb-overview is dependent on a document (rtp > usage) which only has an estimate of 40 percent done) I'd say that the > estimate is probably closer to 40 than 80. I don't know exactly what Cullen meant by the percentages, but I don't think he intended them to be sequential the way publication dependencies are. If, for instance, he was thinking about how many percent of the text needed to change semantically before it was done, I think 80% for "overview" may be right (unless we choose to change the approach by some large delta). If you want to draw up a dependency graph .... well, since -overview- was intended to be the one that points to all the others, it's reasonable to put it last in the graph. That's what it's for. > > > > From: fluffy@iii.ca > > Date: Thu, 4 Jul 2013 17:47:20 -0700 > > To: rtcweb@ietf.org > > Subject: [rtcweb] Question about the status of various drafts > > > > > > As part of putting together some chair slides for Berlin, I'm trying > to get a very rough idea of where things are. I'd like to get folks > input on what percent done various drafts are where Done is a > published RFC. > > > > This is nearly impossible to do at any level of accuracy but I do > want to get a vague idea. I took a very rough stab below just to have > a starting point to get the conversation going. I'm sure my numbers > are mostly wrong but I have tried to ask a few people and sort of take > the central cluster of the guess. If you think I am way out, please > provide some feedback of what you think the number actually is. > > > > I'm happy to get feedback on specific drafts or feedback of the form > they are all too low or too high. I do encourage people to > realistically look at the data tracker to see how long other drafts > have taken for each stage to get a baseline instead of just going with > their gut feel. > > > > Thanks, Cullen > > > > PS - if you are an author and look at the number next to your draft > and think it is way off, please please, say something. > > > > > > > > draft-ietf-rtcweb-overview 80 > > draft-ietf-rtcweb-use-cases-and-requirements 70 > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html 70 > > draft-burnett-rtcweb-constraints-registry 80 > > http://dev.w3.org/2011/webrtc/editor/webrtc.html 50 > > draft-nandakumar-rtcweb-stun-uri 80 > > draft-petithuguenin-behave-turn-uris 80 > > draft-ietf-rtcweb-security 80 > > draft-ietf-rtcweb-security-arch 80 > > draft-muthu-behave-consent-freshness-02 50 > > draft-ietf-rtcweb-data-channel 70 > > draft-ietf-mmusic-sctp-sdp 70 > > draft-jesup-rtcweb-data-protocol 50 > > draft-ietf-tsvwg-sctp-dtls-encaps 70 > > draft-ietf-rtcweb-rtp-usage 40 > > draft-ietf-avtcore-6222bis 80 > > draft-ietf-avtcore-avp-codecs 80 > > draft-ietf-avtcore-srtp-encrypted-header-ext 80 > > draft-ietf-avtext-multiple-clock-rates 70 > > draft-lennox-rtcweb-rtp-media-type-mux 80 > > draft-ietf-avtcore-rtp-circuit-breakers 70 > > draft-ietf-avtcore-multi-media-rtp-session 70 > > draft-lennox-avtcore-rtp-multi-stream 70 > > draft-ietf-rtcweb-jsep 50 > > draft-ietf-mmusic-msid 70 > > draft-rescorla-mmusic-ice-trickle 25 > > draft-ietf-mmusic-sdp-bundle-negotiation 50 > > draft-nandakumar-mmusic-sdp-mux-attributes 25 > > draft-dhesikan-tsvwg-rtcweb-qos 10 or 90 > > draft-ietf-rtcweb-audio 50 > > draft-ietf-payload-rtp-opus 90 > > draft-ietf-payload-vp8-08 95 > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020804010305020801010101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/05/2013 11:25 PM, Bernard Aboba wrote:
I think you need to take dependencies into account.   There are several reasons for this: 

   a. Until you've gone through the dependency graph for the items, the full list of documents that need to be tracked isn't known. 
   b. Estimates of completion are dependent on the progress of normative dependencies (e.g. they can't be published until the dependencies are resolved). 

As an example,  draft-ietf-rtcweb-overview (which is listed as 80 percent complete) has normative references to the following drafts: 

   [I-D.ietf-mmusic-sctp-sdp] 70
   [I-D.ietf-rtcweb-audio] 50
   [I-D.ietf-rtcweb-data-channel] 70
   [I-D.ietf-rtcweb-jsep] 50
   [I-D.ietf-rtcweb-rtp-usage] 40
   [I-D.ietf-rtcweb-security] 80
   [I-D.ietf-rtcweb-security-arch] 80
   [I-D.nandakumar-rtcweb-stun-uri] 80
   [I-D.tuexen-tsvwg-sctp-dtls-encaps] 70
            
Since draft-ietf-rtcweb-overview is dependent on a document (rtp usage) which only has an estimate of 40 percent done) I'd say that the estimate is probably closer to 40 than 80.

I don't know exactly what Cullen meant by the percentages, but I don't think he intended them to be sequential the way publication dependencies are.

If, for instance, he was thinking about how many percent of the text needed to change semantically before it was done, I think 80% for "overview" may be right (unless we choose to change the approach by some large delta).

If you want to draw up a dependency graph .... well, since -overview- was intended to be the one that points to all the others, it's reasonable to put it last in the graph. That's what it's for.




> From: fluffy@iii.ca
> Date: Thu, 4 Jul 2013 17:47:20 -0700
> To: rtcweb@ietf.org
> Subject: [rtcweb] Question about the status of various drafts
>
>
> As part of putting together some chair slides for Berlin, I'm trying to get a very rough idea of where things are. I'd like to get folks input on what percent done various drafts are where Done is a published RFC.
>
> This is nearly impossible to do at any level of accuracy but I do want to get a vague idea. I took a very rough stab below just to have a starting point to get the conversation going. I'm sure my numbers are mostly wrong but I have tried to ask a few people and sort of take the central cluster of the guess. If you think I am way out, please provide some feedback of what you think the number actually is.
>
> I'm happy to get feedback on specific drafts or feedback of the form they are all too low or too high. I do encourage people to realistically look at the data tracker to see how long other drafts have taken for each stage to get a baseline instead of just going with their gut feel.
>
> Thanks, Cullen
>
> PS - if you are an author and look at the number next to your draft and think it is way off, please please, say something.
>
>
>
> draft-ietf-rtcweb-overview 80
> draft-ietf-rtcweb-use-cases-and-requirements 70
> http://dev.w3.org/2011/webrtc/editor/getusermedia.html 70
> draft-burnett-rtcweb-constraints-registry 80
> http://dev.w3.org/2011/webrtc/editor/webrtc.html 50
> draft-nandakumar-rtcweb-stun-uri 80
> draft-petithuguenin-behave-turn-uris 80
> draft-ietf-rtcweb-security 80
> draft-ietf-rtcweb-security-arch 80
> draft-muthu-behave-consent-freshness-02 50
> draft-ietf-rtcweb-data-channel 70
> draft-ietf-mmusic-sctp-sdp 70
> draft-jesup-rtcweb-data-protocol 50
> draft-ietf-tsvwg-sctp-dtls-encaps 70
> draft-ietf-rtcweb-rtp-usage 40
> draft-ietf-avtcore-6222bis 80
> draft-ietf-avtcore-avp-codecs 80
> draft-ietf-avtcore-srtp-encrypted-header-ext 80
> draft-ietf-avtext-multiple-clock-rates 70
> draft-lennox-rtcweb-rtp-media-type-mux 80
> draft-ietf-avtcore-rtp-circuit-breakers 70
> draft-ietf-avtcore-multi-media-rtp-session 70
> draft-lennox-avtcore-rtp-multi-stream 70
> draft-ietf-rtcweb-jsep 50
> draft-ietf-mmusic-msid 70
> draft-rescorla-mmusic-ice-trickle 25
> draft-ietf-mmusic-sdp-bundle-negotiation 50
> draft-nandakumar-mmusic-sdp-mux-attributes 25
> draft-dhesikan-tsvwg-rtcweb-qos 10 or 90
> draft-ietf-rtcweb-audio 50
> draft-ietf-payload-rtp-opus 90
> draft-ietf-payload-vp8-08 95
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


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

--------------020804010305020801010101-- From martin.thomson@gmail.com Sat Jul 27 08:47:35 2013 Return-Path: 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 2D5F821F9AB4 for ; Sat, 27 Jul 2013 08:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 CVYWhE3SqVjG for ; Sat, 27 Jul 2013 08:47:34 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB1D21F9AC4 for ; Sat, 27 Jul 2013 08:47:34 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u57so2803121wes.9 for ; Sat, 27 Jul 2013 08:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jIW3PgZECoudc1Si/DPzWcvQRRq6msjs7bYcp1UehXY=; b=anHaybA6ghJ905o3kJfbkOLQrN0WH6O7h4KKue3mZfxRkHjfIrYvkwRWbfb+LsLPbT N0lIEW84ab11EWJXF/i0bu3LauTfwRYBnkBI6OieXmnNf+86CEaFWWa6uE4Ib8Lxt5ic LMY4S3duBJMRZvlQZSo9D969JihPKjYB+N3MdQUdk3h+DKEbVKel6dibXrNaHAw9Jypp as4s2TPV0IW93tASPCWpZhiAB/Wt2Y1U4habYG8pGDptpMqYz83pdqbEUJudObDBodSL JUZN1ioZoQSX9Qj+3Rj3sS8S9n2YZdcQPkfuTz6eHRii7BphiktwsL2YBrzL1prW1RRY IJfQ== MIME-Version: 1.0 X-Received: by 10.194.110.6 with SMTP id hw6mr38515870wjb.3.1374940053507; Sat, 27 Jul 2013 08:47:33 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Sat, 27 Jul 2013 08:47:33 -0700 (PDT) In-Reply-To: <22027904-8F7D-4CB7-B002-39973D201D7A@cisco.com> References: <3F737E1C-BBF9-4399-8B7D-B50FB4A2FFC0@cisco.com> <22027904-8F7D-4CB7-B002-39973D201D7A@cisco.com> Date: Sat, 27 Jul 2013 08:47:33 -0700 Message-ID: From: Martin Thomson To: Dan Wing Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security Architecture -07 review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 15:47:35 -0000 On 25 July 2013 17:34, Dan Wing wrote: > We could envision a more sophisticated mechanism, based on lots of differ= ent criteria, where different public/private key pairs are used and where s= ome are destroyed immediately after certain calls. For example, I might wa= nt to use a public/private key pair for all of my work calls and leave that= static (as I want that identity to stick with me) but an ephemeral, one-ti= me-only public/private key pair when not engaging in phone calls related to= my work, such as calling my psychologist. I believe that we've (EKR and I, I don't know if this made it to meetings or lists) discussed the need for some application-level control over these credentials. I think that the idea was to allow sites to specify a credential key that would be used to index a table of credentials. Of course, every origin would have to use a different table, which could impose some storage requirements on the browser, requiring some sort or space management to avoid exploitation. By selecting a random credential key for each call (bear with me regarding terminology, I'm making this up as I go) a site could effectively create a new set of credentials for that call. Of course, the site could also choose to generate new credentials for every call to make it impossible (or at least very difficult) to audit calls made on that site, if that is something we cared about. I do think that in the absence of the identity provider system, that is the only advantage that DTLS-SRTP brings, so we'd have to be quite careful here. I don't know what the right answer is. From lars@netapp.com Sun Jul 28 05:06:22 2013 Return-Path: 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 5018321F9D21 for ; Sun, 28 Jul 2013 05:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[AWL=1.482, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 KAKs7BfTRmQm for ; Sun, 28 Jul 2013 05:06:17 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 23BFB21F9D1B for ; Sun, 28 Jul 2013 05:06:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,763,1367996400"; d="scan'208";a="76692967" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx12-out.netapp.com with ESMTP; 28 Jul 2013 05:06:15 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Sun, 28 Jul 2013 05:06:14 -0700 From: "Eggert, Lars" To: "" Thread-Topic: ANRP winner talk on rate control for media streaming in IRTFOPEN Thread-Index: AQHOi4rbhgI2zt5akkGzUcn/8tC0Lw== Date: Sun, 28 Jul 2013 12:06:13 +0000 Message-ID: <2CD7178B-DD63-4785-9ACA-77E8BF36A920@netapp.com> References: <76B78224-2A21-48F2-94ED-FE5CFD32A2BC@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="utf-8" Content-ID: <3BC5ACCC675E374A8E2F89A5BB9EB1EF@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [rtcweb] ANRP winner talk on rate control for media streaming in IRTFOPEN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 12:06:22 -0000 SGksDQoNCnRoZSBmb2xsb3dpbmcgdGFsayBieSBBTlJQIDIwMTMgcHJpemUgd2lubmVyIFRlLVl1 YW4gSHVhbmcgaXMgcHJvYmFibHkgb2YgaW50ZXJlc3QgdG8gc29tZSBSQUkgYW5kIFRTViBmb2xr cy4gVGhlIHRhbGsgd2lsbCBzdGFydCBhdCBhcHByb3guIDk6MTVBTSBvbiBUdWVzZGF5Og0KDQo+ ICAgICoqKiBURS1ZVUFOIEhVQU5HICoqKiBmb3IgaW5zaWdodHMgaW50byB0aGUgZGlmZmljdWx0 aWVzIG9mIHJhdGUNCj4gICAgYWRhcHRhdGlvbiBmb3Igc3RyZWFtaW5nIHZpZGVvOg0KPiANCj4g ICAgICAgIFRlLVl1YW4gSHVhbmcsIE5pa2hpbCBIYW5kaWdvbCwgQnJhbmRvbiBIZWxsZXIsIE5p Y2sgTWNLZW93bg0KPiAgICAgICAgYW5kIFJhbWVzaCBKb2hhcmkuIENvbmZ1c2VkLCBUaW1pZCwg YW5kIFVuc3RhYmxlOiBQaWNraW5nIGENCj4gICAgICAgIFZpZGVvIFN0cmVhbWluZyBSYXRlIGlz IEhhcmQuIFByb2MuIEFDTSBJbnRlcm5ldCBNZWFzdXJlbWVudA0KPiAgICAgICAgQ29uZmVyZW5j ZSAoSU1DKSxOb3ZlbWJlciAyMDEyLCBCb3N0b24sIE1BLCBVU0EuDQo+IA0KPiAgICAgICAgVG9k YXnigJlzIGNvbW1lcmNpYWwgdmlkZW8gc3RyZWFtaW5nIHNlcnZpY2VzIHVzZSBkeW5hbWljIHJh dGUNCj4gICAgICAgIHNlbGVjdGlvbiB0byBwcm92aWRlIGEgaGlnaC1xdWFsaXR5IHVzZXIgZXhw ZXJpZW5jZS4gV2UNCj4gICAgICAgIG1lYXN1cmUgdGhyZWUgcG9wdWxhciB2aWRlbyBzdHJlYW1p bmcgc2VydmljZXMgYW5kIO+sgW5kIHRoYXQNCj4gICAgICAgIGFjY3VyYXRlIGNsaWVudC1zaWRl IGJhbmR3aWR0aCBlc3RpbWF0aW9uIGFib3ZlIHRoZSBIVFRQDQo+ICAgICAgICBsYXllciBpcyBo YXJkLiBBcyBhIHJlc3VsdCwgcmF0ZSBzZWxlY3Rpb24gYmFzZWQgb24NCj4gICAgICAgIGluYWNj dXJhdGUgZXN0aW1hdGVzIGNhbiB0cmlnZ2VyIGEgZmVlZGJhY2sgbG9vcCwgbGVhZGluZyB0bw0K PiAgICAgICAgdW5kZXNpcmFibHkgdmFyaWFibGUgYW5kIGxvdy1xdWFsaXR5IHZpZGVvLiBJbiB0 aGlzIHRhbGssIHdlDQo+ICAgICAgICB3aWxsIHByZXNlbnQgaW5zaWdodHMgaW50byBpdHMgcm9v dCBjYXVzZXMgYW5kIHZhbGlkYXRlDQo+ICAgICAgICBpbml0aWFsIHNvbHV0aW9ucyB0byBwcmV2 ZW50IGl0Lg0KDQpMYXJz From tterriberry@mozilla.com Mon Jul 29 02:16:21 2013 Return-Path: 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 BBBE621F9DBE for ; Mon, 29 Jul 2013 02:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] 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 zzXgUYilzOmy for ; Mon, 29 Jul 2013 02:16:15 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 41D2721F9E00 for ; Mon, 29 Jul 2013 02:16:15 -0700 (PDT) Received: from [130.129.33.240] (dhcp-21f0.meeting.ietf.org [130.129.33.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 0C422F225E for ; Mon, 29 Jul 2013 02:16:13 -0700 (PDT) Message-ID: <51F632D6.1050507@mozilla.com> Date: Mon, 29 Jul 2013 02:16:06 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <51BAC9BC.6070708@ericsson.com> <94846970-4694-4EC8-AEFA-AEECEE0135AA@oracle.com> <51C02EE8.5070809@ericsson.com> <8E9D2A9F-3D8B-4480-A85D-320CF30FEAA6@oracle.com> <30761469-F5CC-4858-8D40-4632A7D5A682@oracle.com> <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> In-Reply-To: <529DCF4E-2A8B-475F-8CCE-7E2ABC72EFB1@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] No Interim on SDES at this juncture X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 09:16:21 -0000 Hadriel Kaplan wrote: > Right, and I'm hoping the Browser vendors can tell us if browsers can safely know whether all the JS running on a given page is from HTTPS or not, and not allow SDES if the JS is not all from (signed) HTTPS. If not, then I agree that's another negative downside for SDES. In fact I think it's even a problem for DTLS-SRTP. I don't know why we'd be ok with using HTTP at all, if we're *truly* concerned about MitM and malicious 3rd party JS attacks. Yes, this is detectable. As I said at the mic in Beijing, however, this is a property that can change at any time, because a page can load script from a new, programmatically constructed URL at any point. See Section 5.1 of the updated draft-ietf-rtcweb-security-arch-07. That makes it difficult to design security policy guarantees (it might seem "safe" to access a resource when you ask to access it, but very difficult to revoke access later when you realize it's not safe). For that reason among many others, browsers have been moving to simply block mixed content entirely. See . Firefox will release this in August. Chrome already does this. IE has prompted users since at least IE 7. From tterriberry@mozilla.com Mon Jul 29 02:16:44 2013 Return-Path: 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 542BA21F9DBE for ; Mon, 29 Jul 2013 02:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] 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 qDd9ivErmOLu for ; Mon, 29 Jul 2013 02:16:38 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id C6E9721F9F62 for ; Mon, 29 Jul 2013 02:16:37 -0700 (PDT) Received: from [130.129.33.240] (dhcp-21f0.meeting.ietf.org [130.129.33.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 43E91F2264 for ; Mon, 29 Jul 2013 02:16:37 -0700 (PDT) Message-ID: <51F632F3.4010605@mozilla.com> Date: Mon, 29 Jul 2013 02:16:35 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 09:16:44 -0000 Iñaki Baz Castillo wrote: > for WebRTC" (this is true). I also remember that somebody proposed > that the browser should include a "call history" panel, which clearly > shows a limited and wrong WWW vision. I recall EKR proposing an audit log for camera access. But the reasons for this were entirely related to security (an app with persistent permissions won't be as ready to abuse them if it knows it will leave a trail in logs not under its control). I thought it was a really good idea. I still do. From ibc@aliax.net Mon Jul 29 02:37:45 2013 Return-Path: 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 520E611E80A2 for ; Mon, 29 Jul 2013 02:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 WOJ4YZe3sRTB for ; Mon, 29 Jul 2013 02:37:39 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E416521F9AC5 for ; Mon, 29 Jul 2013 02:37:38 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id a1so195344qcx.17 for ; Mon, 29 Jul 2013 02:37:38 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=y4uw42JX4V7NcPqxC1MHq8D3QOJbtMjYeTxoLhA4JRM=; b=PBRzB6i+zuXpyKZf8E7g+zjlPB0EBXQngi645QDw36eQhwI5hkLqtBq2CJY8z4taCw hRF7ehdRF5zi3LfFsbEbgGLe5XF0neqvzQmufeEmSvmNFxjA96NR0ETC2PvaDxhmfdwG Xx5hupuM6FmRnb23dCQEGYP4dniKybro/pW5Dyp7+/dfdkyV6nfmJz0KFI25IVYIXN11 hJUdk+ZYw2mr3g3sS5uynm3yQhjNH48eT3gXebUyMdRq0qdcnf3BgLrK27kBhXOBvikn T6uSDzMnSkIPuvbM8afaJSy5liwSFGATMrAgsdyylIyXwBf4aTvmVJ7FanCsrgmB85Pp Xd6Q== X-Received: by 10.224.90.1 with SMTP id g1mr71828901qam.0.1375090658341; Mon, 29 Jul 2013 02:37:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 02:37:18 -0700 (PDT) In-Reply-To: <51F632F3.4010605@mozilla.com> References: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <51F632F3.4010605@mozilla.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 29 Jul 2013 11:37:18 +0200 Message-ID: To: "Timothy B. Terriberry" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlj5IEf6LAZVcDT2AnCC7iyHOWtrsFeSiw0qAYP4USF6ISDtRlge+gfUfJsPtRLNAjVFCyB Cc: "rtcweb@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 09:37:45 -0000 2013/7/29 Timothy B. Terriberry : > I=C3=B1aki Baz Castillo wrote: >> >> for WebRTC" (this is true). I also remember that somebody proposed >> that the browser should include a "call history" panel, which clearly >> shows a limited and wrong WWW vision. > > > I recall EKR proposing an audit log for camera access. But the reasons fo= r > this were entirely related to security (an app with persistent permission= s > won't be as ready to abuse them if it knows it will leave a trail in logs > not under its control). > > I thought it was a really good idea. I still do. What I meant was somebody requesting a "Call history panel" in the browser (similar to the "Favorites panel" or the "Navigation History panel"). ;) --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jul 29 10:34:00 2013 Return-Path: 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 0588A21F86B2 for ; Mon, 29 Jul 2013 10:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 8xaqnblKwn5z for ; Mon, 29 Jul 2013 10:33:55 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEE221F880F for ; Mon, 29 Jul 2013 10:32:16 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so3035855qcz.14 for ; Mon, 29 Jul 2013 10:32:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=EzyBKLS+8tEHLTWKtjxlGPmaAQuVOQ0RQpsqVmDKMl4=; b=YqVSneMlqI1I+2ksxDmoXvPc85LHvCvul9eY8Qp/xWswPhmLSbzn3tByXIKKBKgkdm Bt6T/r5m1yXYx7EVZKWT/e6NlsqmwGvcIxe8k4vr1OB0ra4E+APmvrDXAHwmGU1ThiAT gEpO1lLjcpeHephit7RVBs/vgR1IQ38kS7U4p9SDY/4v0a/RgoKSG8suKnYKedVvkF7H DVD6odv/axQQdAey1NRUUVt1OXlL2xhHQBTgojQa5AN1fXHdN0LMFvN6gg1rb6cDFm/z EaOjFCm9UpbBkiU2Wk0uB+Iz1+xVoxdN/LlktA4OPZWyVxsn7v9BN9kLHIQ6brA3GAOM l+XA== X-Received: by 10.49.117.165 with SMTP id kf5mr30773851qeb.9.1375119135445; Mon, 29 Jul 2013 10:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 10:31:55 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 29 Jul 2013 19:31:55 +0200 Message-ID: To: "rtcweb@ietf.org" , "public-webrtc@w3.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmMiqmKnsiIXT+aKd1kEjMvE1yTrRvUFmJcdsNl5+h1gSnJffsE+iSg+IC9v5quYXSPzt1G Subject: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:34:00 -0000 Hi, I initiated a thread [*] about Plan-Unified and multiple m lines, but it was moved to MMUSIC maillist (don't know why since it is about WebRTC applications design): http://www.ietf.org/mail-archive/web/mmusic/current/msg11966.html Sorry for the cross-posting but at this point I'm a bit lost and do not know which is the appropriate group for my concern. So my concern is: - Web application with a SIP over WebSocket client running in the web. - The web user is provided with a conference SIP URI in which there are *already* 8 participants (5 of them emitting audio and video and 3 just emitting audio). - The user calls, from his webphone, to the given URI to join the conferenc= e. Let's imagine that the JS app knows the number of participant in the confer= ence. Let's imagine my browser have mic and webcam. QUESTION: How can my browser join the conference without requiring SDP renegotiation from the server and, at the same time, being able to send audio/video and receive audio/video from others (different tracks / m=3Dlines)? "SOLUTIONS": 1) I tell my browser to generate a SDP offer with: - 1 send/receive m=3Daudio line. - 7 recvonly m=3Daudio line. - 1 send/only m=3Dvideo line. - 4 recvonly m=3Dvideo line. (Obviously this is a joke) 2) SDP seems to allow that the offer and the answer have different number of m lines (I'm not aware of that but I believe that SDP can do "everything"). So my browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo line, and the server replies with 8 m=3Daudio lines and 4 m=3Dvideo lines. Will my browser understand such a SDP answer with more m lines than its generated offer? I assume NOT. 3) My browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo line and the server too. And later the server sends re-INVITE with all the m lines. Oppss, SDP renegotiation... SDP is bad for WebRTC. SDP is good for legacy symmetric communications in which there is a single-track audio communication and, of course, both endpoints emit audio. But SDP is bad for modern RTC protocols in which an endpoint can emit tons of tracks to a single endpoint. Do we really want this for WebRTC 1.0 ? --=20 I=C3=B1aki Baz Castillo From piranna@gmail.com Mon Jul 29 10:43:03 2013 Return-Path: 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 7FA9411E80E9 for ; Mon, 29 Jul 2013 10:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 9mbkvzzBeiCS for ; Mon, 29 Jul 2013 10:43:01 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF3F21F9A3D for ; Mon, 29 Jul 2013 10:43:00 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u57so4154970wes.23 for ; Mon, 29 Jul 2013 10:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bNEc+Kqg0rzAjGb0JSjFDHyNYm+2V81Rj3X0jwlepsY=; b=TfgF5lFa00XqHs0Sx6yVbjNcqwfBxaR62C4POPrxnOA5Cmh0O/55SZpgN/pOhyeA4I CyuPZJB+N2ZO6i93ks6JxbGHvCa3YEVyTQm0rlOA7QW2xdImwAzPhyjVqgnQRe1iE23z yEbEw42XCSRhT4kouIRP80dBBUWws7jZ7P5664zSO9G3E0GtIYd2U3/orDTAcKa2wGjy DQ9LWpyjVIEHMUXJPkilg17Ox/g/HQ0bGrDNgbS/jj69WYC5H09cwfW/wBZOd7v3rC38 EoRza/CZqoDOfqubyB9CPSUx62PCwTF3RJ+uFS90priWrLcxl0uuba2kWddtgYrprKGA xIfg== MIME-Version: 1.0 X-Received: by 10.180.9.235 with SMTP id d11mr7860537wib.35.1375119779439; Mon, 29 Jul 2013 10:42:59 -0700 (PDT) Received: by 10.195.13.75 with HTTP; Mon, 29 Jul 2013 10:42:59 -0700 (PDT) Received: by 10.195.13.75 with HTTP; Mon, 29 Jul 2013 10:42:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jul 2013 19:42:59 +0200 Message-ID: From: "piranna@gmail.com" To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c2195afa347f04e2aa0538 Cc: rtcweb@ietf.org, public-webrtc Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:43:03 -0000 --001a11c2195afa347f04e2aa0538 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, this scenario seems more of a beta or maybe an alpha than a polished 1.0 version. El 29/07/2013 19:34, "I=F1aki Baz Castillo" escribi=F3: > Hi, I initiated a thread [*] about Plan-Unified and multiple m lines, > but it was moved to MMUSIC maillist (don't know why since it is about > WebRTC applications design): > > http://www.ietf.org/mail-archive/web/mmusic/current/msg11966.html > > Sorry for the cross-posting but at this point I'm a bit lost and do > not know which is the appropriate group for my concern. > > > > So my concern is: > > > - Web application with a SIP over WebSocket client running in the web. > > - The web user is provided with a conference SIP URI in which there > are *already* 8 participants (5 of them emitting audio and video and 3 > just emitting audio). > > - The user calls, from his webphone, to the given URI to join the > conference. > > > > Let's imagine that the JS app knows the number of participant in the > conference. > Let's imagine my browser have mic and webcam. > > > > QUESTION: > > How can my browser join the conference without requiring SDP > renegotiation from the server and, at the same time, being able to > send audio/video and receive audio/video from others (different tracks > / m=3Dlines)? > > > > > "SOLUTIONS": > > > > 1) > > I tell my browser to generate a SDP offer with: > > - 1 send/receive m=3Daudio line. > - 7 recvonly m=3Daudio line. > - 1 send/only m=3Dvideo line. > - 4 recvonly m=3Dvideo line. > > (Obviously this is a joke) > > > > 2) > > SDP seems to allow that the offer and the answer have different number > of m lines (I'm not aware of that but I believe that SDP can do > "everything"). So my browser generates a SDP offer with 1 m=3Daudio line > and 1 m=3Dvideo line, and the server replies with 8 m=3Daudio lines and 4 > m=3Dvideo lines. > > Will my browser understand such a SDP answer with more m lines than > its generated offer? I assume NOT. > > > > 3) > > My browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo > line and the server too. And later the server sends re-INVITE with all > the m lines. > > Oppss, SDP renegotiation... > > > > > SDP is bad for WebRTC. SDP is good for legacy symmetric communications > in which there is a single-track audio communication and, of course, > both endpoints emit audio. But SDP is bad for modern RTC protocols in > which an endpoint can emit tons of tracks to a single endpoint. > > > Do we really want this for WebRTC 1.0 ? > > > -- > I=F1aki Baz Castillo > > > --001a11c2195afa347f04e2aa0538 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

No, this scenario seems more of a beta or maybe an alpha tha= n a polished 1.0 version.

El 29/07/2013 19:34, "I=F1aki Baz Castillo&= quot; <ibc@aliax.net> escribi=F3= :
Hi, I initiated a thread [*] about Plan-Unified and multiple m lines,
but it was moved to MMUSIC maillist (don't know why since it is about WebRTC applications design):

http://www.ietf.org/mail-archive/web/mmusic/current/ms= g11966.html

Sorry for the cross-posting but at this point I'm a bit lost and do
not know which is the appropriate group for my concern.



So my concern is:


- Web application with a SIP over WebSocket client running in the web.

- The web user is provided with a conference SIP URI in which there
are *already* 8 participants (5 of them emitting audio and video and 3
just emitting audio).

- The user calls, from his webphone, to the given URI to join the conferenc= e.



Let's imagine that the JS app knows the number of participant in the co= nference.
Let's imagine my browser have mic and webcam.



QUESTION:

How can my browser join the conference without requiring SDP
renegotiation from the server and, at the same time, being able to
send audio/video and receive audio/video from others (different tracks
/ m=3Dlines)?




"SOLUTIONS":



1)

I tell my browser to generate a SDP offer with:

=A0 - 1 send/receive m=3Daudio line.
=A0 - 7 recvonly m=3Daudio line.
=A0 - 1 send/only m=3Dvideo line.
=A0 - 4 recvonly m=3Dvideo line.

(Obviously this is a joke)



2)

SDP seems to allow that the offer and the answer have different number
of m lines (I'm not aware of that but I believe that SDP can do
"everything"). So my browser generates a SDP offer with 1 m=3Daud= io line
and 1 m=3Dvideo line, and the server replies with 8 m=3Daudio lines and 4 m=3Dvideo lines.

Will my browser understand such a SDP answer with more m lines than
its generated offer? I assume NOT.



3)

My browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo
line and the server too. And later the server sends re-INVITE with all
the m lines.

Oppss, SDP renegotiation...




SDP is bad for WebRTC. SDP is good for legacy symmetric communications
in which there is a single-track audio communication and, of course,
both endpoints emit audio. But SDP is bad for modern RTC protocols in
which an endpoint can emit tons of tracks to a single endpoint.


Do we really want this for WebRTC 1.0 ?


--
I=F1aki Baz Castillo
<ibc@aliax.net>

--001a11c2195afa347f04e2aa0538-- From bossiel@yahoo.fr Mon Jul 29 10:45:32 2013 Return-Path: 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 A40FB21F9A35 for ; Mon, 29 Jul 2013 10:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 wepGUClonYvq for ; Mon, 29 Jul 2013 10:45:26 -0700 (PDT) Received: from nm13-vm0.bullet.mail.ird.yahoo.com (nm13-vm0.bullet.mail.ird.yahoo.com [77.238.189.195]) by ietfa.amsl.com (Postfix) with SMTP id 6FD0621F8427 for ; Mon, 29 Jul 2013 10:45:13 -0700 (PDT) Received: from [77.238.189.50] by nm13.bullet.mail.ird.yahoo.com with NNFMP; 29 Jul 2013 17:45:11 -0000 Received: from [212.82.108.243] by tm3.bullet.mail.ird.yahoo.com with NNFMP; 29 Jul 2013 17:45:10 -0000 Received: from [127.0.0.1] by omp1008.mail.ird.yahoo.com with NNFMP; 29 Jul 2013 17:45:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 974894.2338.bm@omp1008.mail.ird.yahoo.com Received: (qmail 76922 invoked by uid 60001); 29 Jul 2013 17:45:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1375119910; bh=EOkC1I2GcnRR6nzD2Jt+OEpcP4gpHiUkNMk67hZgyjo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=GfoLOU3BxlWzveiJYb8Pm1sgSq/v80V+/u6IQTtD1yJQO9LzhezKdZI3e7mkTOThAmXhkbHIbz1qKH9+PBWU8ENiJKkp3O7qqt4GCCoJo5EuyHiJzYQJyBR0Fk9HAQ5ROEJxhxRrUC42ciuj0VGMqiL0O8gTY4WXTO/ynNlOkv4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2tpivj/JLPUM6hV2tRt/XmFigB0CvM7JMSh/1l9TYhFp8qhsLBe1o18jFnDDskF1d7IPQAxbk02yk3aC4ZqhUxW5r9dYKHz7/keWMqQeGgKhoXI4DGQNJ3oSLmbJuFDVWJJXYgDrlzkYtZRN5iV6szYAseh3wjgg7QDdecdSL3I=; X-YMail-OSG: Q4oT19IVM1ncXoquQiAsRJIBvfctuuwa76deUzp42_gUSqd yl4biOFRIJHqoCZC1pBWIr0VVgclcTGQedz0_5HIqeaG7TvijozS.PXdjRVO zGR_ceg_Vzo2lSm_PsSIW7fKdXYp_frTHRWr9QBrD4jzPx1fcaClJL6zLy5g MYCkHWFZh0ZdwcdU5WEn5iz.eKNvaTKvD4kuzDBXboOdq72bWiAyg87R7DGK Whc9ZPRoX396vbss4WgM6s2P4aH7sEHBUdqbN7iueRkIuLft_Xn0fqEMWzHI 9apwoR8MUyy3hmAuXEzHz5e4CSYDB_lcuhTsfv5epWvjHncq1uxWS1C0ewaa 6_86v5yopsrNFT5rTN13HQwcwUAdpTFmlxiQtvOslpBmlvIK.ZFd1032AMds AFk7hH5lNbKbVMPhnTjfyYxjXbgE_JGzv6.9xIGmpWhb97Xl6bf1JJCndWPS 5idLthcUcAdwc2gNCB1unxQgvimY9d3ih98htNDSTSQk7NcENdOltaEF_3OB 2ny26Cas8jgXO2P3EZwprO0znQKbnY4qy1RVX Received: from [88.179.39.5] by web171302.mail.ir2.yahoo.com via HTTP; Mon, 29 Jul 2013 18:45:10 BST X-Rocket-MIMEInfo: 002.001, WW91IHNhaWQ6ICIyKQpTRFAgc2VlbXMgdG8gYWxsb3cgdGhhdCB0aGUgb2ZmZXIgYW5kIHRoZSBhbnN3ZXIgaGF2ZSBkaWZmZXJlbnQgbnVtYmVyCm9mIG0gbGluZXPCoCIKCgpObyBhdCBhbGw6ClJGQyAzMjY0OgpGb3IgZWFjaCAibT0iIGxpbmUgaW4gdGhlIG9mZmVyLCB0aGVyZSBNVVNUIGJlIGEgY29ycmVzcG9uZGluZyAibT0iCmxpbmUgaW4gdGhlIGFuc3dlci4gIFRoZSBhbnN3ZXIgTVVTVCBjb250YWluIGV4YWN0bHkgdGhlIHNhbWUgbnVtYmVyIG9mICJtPSIgbGluZXMgYXMgdGhlIG9mZmVyLiAgVGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.150.561 References: Message-ID: <1375119910.76535.YahooMailNeo@web171302.mail.ir2.yahoo.com> Date: Mon, 29 Jul 2013 18:45:10 +0100 (BST) From: Bossiel thioriguel To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "rtcweb@ietf.org" , "public-webrtc@w3.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1670751155-1967887231-1375119910=:76535" Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bossiel thioriguel List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:45:32 -0000 --1670751155-1967887231-1375119910=:76535 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable You said: "2)=0ASDP seems to allow that the offer and the answer have diffe= rent number=0Aof m lines=A0"=0A=0A=0ANo at all:=0ARFC 3264:=0AFor each "m= =3D" line in the offer, there MUST be a corresponding "m=3D"=0Aline in the = answer. The answer MUST contain exactly the same number of "m=3D" lines as= the offer. This allows for streams to be matched up based on their order.= This implies that if the offer contained zero "m=3D" lines, the answer MU= ST contain zero "m=3D" lines.=0AMamadou.=0A=0A_____________________________= ___=0A De=A0: I=F1aki Baz Castillo =0A=C0=A0: "rtcweb@ietf.o= rg" ; "public-webrtc@w3.org" =0AEnv= oy=E9 le : Lundi 29 juillet 2013 19h31=0AObjet=A0: [rtcweb] SDP is not suit= able for WebRTC=0A =0A=0AHi, I initiated a thread [*] about Plan-Unified an= d multiple m lines,=0Abut it was moved to MMUSIC maillist (don't know why s= ince it is about=0AWebRTC applications design):=0A=0Ahttp://www.ietf.org/ma= il-archive/web/mmusic/current/msg11966.html=0A=0ASorry for the cross-postin= g but at this point I'm a bit lost and do=0Anot know which is the appropria= te group for my concern.=0A=0A=0A=0ASo my concern is:=0A=0A=0A- Web applica= tion with a SIP over WebSocket client running in the web.=0A=0A- The web us= er is provided with a conference SIP URI in which there=0Aare *already* 8 p= articipants (5 of them emitting audio and video and 3=0Ajust emitting audio= ).=0A=0A- The user calls, from his webphone, to the given URI to join the c= onference.=0A=0A=0A=0ALet's imagine that the JS app knows the number of par= ticipant in the conference.=0ALet's imagine my browser have mic and webcam.= =0A=0A=0A=0AQUESTION:=0A=0AHow can my browser join the conference without r= equiring SDP=0Arenegotiation from the server and, at the same time, being a= ble to=0Asend audio/video and receive audio/video from others (different tr= acks=0A/ m=3Dlines)?=0A=0A=0A=0A=0A"SOLUTIONS":=0A=0A=0A=0A1)=0A=0AI tell m= y browser to generate a SDP offer with:=0A=0A=A0 - 1 send/receive m=3Daudio= line.=0A=A0 - 7 recvonly m=3Daudio line.=0A=A0 - 1 send/only m=3Dvideo lin= e.=0A=A0 - 4 recvonly m=3Dvideo line.=0A=0A(Obviously this is a joke)=0A=0A= =0A=0A2)=0A=0ASDP seems to allow that the offer and the answer have differe= nt number=0Aof m lines (I'm not aware of that but I believe that SDP can do= =0A"everything"). So my browser generates a SDP offer with 1 m=3Daudio line= =0Aand 1 m=3Dvideo line, and the server replies with 8 m=3Daudio lines and = 4=0Am=3Dvideo lines.=0A=0AWill my browser understand such a SDP answer with= more m lines than=0Aits generated offer? I assume NOT.=0A=0A=0A=0A3)=0A=0A= My browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo=0Ali= ne and the server too. And later the server sends re-INVITE with all=0Athe = m lines.=0A=0AOppss, SDP renegotiation...=0A=0A=0A=0A=0ASDP is bad for WebR= TC. SDP is good for legacy symmetric communications=0Ain which there is a s= ingle-track audio communication and, of course,=0Aboth endpoints emit audio= . But SDP is bad for modern RTC protocols in=0Awhich an endpoint can emit t= ons of tracks to a single endpoint.=0A=0A=0ADo we really want this for WebR= TC 1.0 ?=0A=0A=0A-- =0AI=F1aki Baz Castillo=0A=0A___________= ____________________________________=0Artcweb mailing list=0Artcweb@ietf.or= g=0Ahttps://www.ietf.org/mailman/listinfo/rtcweb --1670751155-1967887231-1375119910=:76535 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
You said: = "2)

SDP seems to al= low that the offer and the answer have different number
of m lines = "

No at all:
RFC 32= 64:
For each "m=3D" line = in the offer, there MUST be a corresponding "m=3D"
   line in the answer=
.  The answer MUST contain exactly the same number=0A   of "m=3D" lines as =
the offer.  This allows for streams to be matched up=0A   based on their or=
der.  This implies that if the offer contained zero=0A   "m=3D" lines, the =
answer MUST contain zero "m=3D" lines.
Mamadou.
<= span style=3D"font-weight:bold;">De : I=F1aki Baz Castillo = <ibc@aliax.net>
=C0 :<= /span> "rtcweb@ietf.org" <rtcweb@ietf.org>; "public-webrtc@w3.org= " <public-webrtc@w3.org>
E= nvoy=E9 le : Lundi 29 juillet 2013 19h31
Objet : [rtcweb] SDP is not suitable for= WebRTC

Hi, I initiat= ed a thread [*] about Plan-Unified and multiple m lines,
but it was move= d to MMUSIC maillist (don't know why since it is about
WebRTC application= s design):

http://www.ietf.org/mail-archive/web= /mmusic/current/msg11966.html

Sorry for the cross-posting but at= this point I'm a bit lost and do
not know which is the appropriate grou= p for my concern.



So my concern is:


- Web applica= tion with a SIP over WebSocket client running in the web.

- The web = user is provided with a conference SIP URI in which there
are *already* = 8 participants (5 of them emitting audio and video and 3
just emitting a= udio).

- The user calls, from his webphone, to the given URI to join= the conference.



Let's imagine that the JS app knows the num= ber of participant in the conference.
Let's imagine my browser have mic = and webcam.



QUESTION:

How can my browser join the conference without requiring SDP
renegotiation from the server and, at = the same time, being able to
send audio/video and receive audio/video fr= om others (different tracks
/ m=3Dlines)?




"SOLUTIONS"= :



1)

I tell my browser to generate a SDP offer with:<= br>
  - 1 send/receive m=3Daudio line.
  - 7 recvonly m=3Da= udio line.
  - 1 send/only m=3Dvideo line.
  - 4 recvonly m= =3Dvideo line.

(Obviously this is a joke)



2)

S= DP seems to allow that the offer and the answer have different number
of= m lines (I'm not aware of that but I believe that SDP can do
"everythin= g"). So my browser generates a SDP offer with 1 m=3Daudio line
and 1 m= =3Dvideo line, and the server replies with 8 m=3Daudio lines and 4
m=3Dv= ideo lines.

Will my browser understand such a SDP answer with more m= lines than
its generated offer? I assume NOT.



3)

= My browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo
line and th= e server too. And later the server sends re-INVITE with all
the m lines.=

Oppss, SDP renegotiation...




SDP is bad for WebRT= C. SDP is good for legacy symmetric communications
in which there is a s= ingle-track audio communication and, of course,
both endpoints emit audi= o. But SDP is bad for modern RTC protocols in
which an endpoint can emit= tons of tracks to a single endpoint.


Do we really want this for= WebRTC 1.0 ?


--
I=F1aki Baz Castillo
<ibc@aliax.net>_______________________________________________
rtcweb mailing list
= rtcwe= b@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

<= br>
--1670751155-1967887231-1375119910=:76535-- From ibc@aliax.net Mon Jul 29 10:50:40 2013 Return-Path: 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 88D5121F9C8B for ; Mon, 29 Jul 2013 10:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 RdNQAipvb+Qz for ; Mon, 29 Jul 2013 10:50:07 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3681D21F9A50 for ; Mon, 29 Jul 2013 10:50:04 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id c11so2033227qcv.27 for ; Mon, 29 Jul 2013 10:49:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=L8dj04nslYZjOsGkfZjGru0i+IGa4CO/I7t4XA0AUdc=; b=axhq3Y+e9/x8LIeWjFvfQmp5f2rJQPhfzZxnnkCZtzIDUJdkV+/lY/pmACnRd5dMqk gN+gtD3GKlChAdAoIQy7tFR8YD0p8mYDm4i/ht7avRMJqRwE6T3jaYwHDaGr1a8GTqbW Kj8ZWGKSBls3YJWy+zeFk7rTH2ntjQak/sF5/wazfrMsVwFDmaRgTejAesaKsyx3Z3lu sfYYKVZ3wmsKpiOH6eQ3fEvV35Nq2JV+GzdwKbKzk90XD+NqZWUGbGIoXDJv/3Ps8PS+ TPuld7dx9DM97dQu5/jjN2LXvpWPnCMfC21dxftY6MjhQbAVXhniFq96pKQkAsXGs2rw YOFA== MIME-Version: 1.0 X-Received: by 10.229.16.207 with SMTP id p15mr5890154qca.47.1375120198810; Mon, 29 Jul 2013 10:49:58 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 10:49:58 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 10:49:58 -0700 (PDT) In-Reply-To: <1375119910.76535.YahooMailNeo@web171302.mail.ir2.yahoo.com> References: <1375119910.76535.YahooMailNeo@web171302.mail.ir2.yahoo.com> Date: Mon, 29 Jul 2013 19:49:58 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bossiel thioriguel Content-Type: multipart/alternative; boundary=0015175df19ef975ed04e2aa1e7a X-Gm-Message-State: ALoCoQnSziW3HCKoslyH8SZ9cMzBTUNl/Xj66z20j4PYwehHVGjQPGp21P59BWjn0j2xSPvZrtfH Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:50:40 -0000 --0015175df19ef975ed04e2aa1e7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks a lot for clarifying it. So Christer was wrong ;) And it makes my scenario even worse. I really hope something will happen and WebRTC will get rid of SDP... -- I=C3=B1aki Baz Castillo El 29/07/2013 19:45, "Bossiel thioriguel" escribi=C3=B3: > You said: "2) > > SDP seems to allow that the offer and the answer have different number > of m lines " > > No at all: > RFC 3264: > For each "m=3D" line in the offer, there MUST be a corresponding "m=3D" > > line in the answer. The answer MUST contain exactly the same number > of "m=3D" lines as the offer. This allows for streams to be matched u= p > based on their order. This implies that if the offer contained zero > "m=3D" lines, the answer MUST contain zero "m=3D" lines. > > Mamadou. > > ------------------------------ > *De :* I=C3=B1aki Baz Castillo > *=C3=80 :* "rtcweb@ietf.org" ; "public-webrtc@w3.org" < > public-webrtc@w3.org> > *Envoy=C3=A9 le :* Lundi 29 juillet 2013 19h31 > *Objet :* [rtcweb] SDP is not suitable for WebRTC > > Hi, I initiated a thread [*] about Plan-Unified and multiple m lines, > but it was moved to MMUSIC maillist (don't know why since it is about > WebRTC applications design): > > http://www.ietf.org/mail-archive/web/mmusic/current/msg11966.html > > Sorry for the cross-posting but at this point I'm a bit lost and do > not know which is the appropriate group for my concern. > > > > So my concern is: > > > - Web application with a SIP over WebSocket client running in the web. > > - The web user is provided with a conference SIP URI in which there > are *already* 8 participants (5 of them emitting audio and video and 3 > just emitting audio). > > - The user calls, from his webphone, to the given URI to join the > conference. > > > > Let's imagine that the JS app knows the number of participant in the > conference. > Let's imagine my browser have mic and webcam. > > > > QUESTION: > > How can my browser join the conference without requiring SDP > renegotiation from the server and, at the same time, being able to > send audio/video and receive audio/video from others (different tracks > / m=3Dlines)? > > > > > "SOLUTIONS": > > > > 1) > > I tell my browser to generate a SDP offer with: > > - 1 send/receive m=3Daudio line. > - 7 recvonly m=3Daudio line. > - 1 send/only m=3Dvideo line. > - 4 recvonly m=3Dvideo line. > > (Obviously this is a joke) > > > > 2) > > SDP seems to allow that the offer and the answer have different number > of m lines (I'm not aware of that but I believe that SDP can do > "everything"). So my browser generates a SDP offer with 1 m=3Daudio line > and 1 m=3Dvideo line, and the server replies with 8 m=3Daudio lines and 4 > m=3Dvideo lines. > > Will my browser understand such a SDP answer with more m lines than > its generated offer? I assume NOT. > > > > 3) > > My browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo > line and the server too. And later the server sends re-INVITE with all > the m lines. > > Oppss, SDP renegotiation... > > > > > SDP is bad for WebRTC. SDP is good for legacy symmetric communications > in which there is a single-track audio communication and, of course, > both endpoints emit audio. But SDP is bad for modern RTC protocols in > which an endpoint can emit tons of tracks to a single endpoint. > > > Do we really want this for WebRTC 1.0 ? > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --0015175df19ef975ed04e2aa1e7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks a lot for clarifying it. So Christer was wrong ;)

And it makes my scenario even worse. I really hope something= will happen and WebRTC will get rid of SDP...

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

El 29/07/2013 19:45, "Bossiel thioriguel&qu= ot; <bossiel@yahoo.fr> escrib= i=C3=B3:
You said: "2= )

SDP seems to allow that the offer and the answer have dif= ferent number
of m lines=C2=A0"

No at all:
RFC 3264:
For = each "m=3D" line in the offer, there MUST be a corresponding &quo= t;m=3D"
   line in th=
e answer.  The answer MUST contain exactly the same number
   of "m=3D" lines as the offer.  This allows for streams to be m=
atched up
   based on their order.  This implies that if the offer contained zero
   "m=3D" lines, the answer MUST contain zero "m=3D" li=
nes.
Mamadou.=
De=C2=A0: I=C3=B1aki= Baz Castillo <ibc@al= iax.net>
=C3=80=C2=A0: "rtcweb@ietf.org" <= ;rtcweb@ietf.org&g= t;; "public-= webrtc@w3.org" <public-webrtc@w3.org>
Envoy=C3=A9 le : Lundi 29 j= uillet 2013 19h31
Objet=C2=A0: [rtcweb] SDP is not suitable for WebRTC

= Hi, I initiated a thread [*] about Plan-Unified and multiple m lines,
but it was moved to MMUSIC maillist (don't know why since it is about
WebRTC applica= tions design):

http://www.ietf.org/mail-archive= /web/mmusic/current/msg11966.html

Sorry for the cross-posting but at this point I'm a bit lost and do=
not know which is the appropriate group for my concern.



= So my concern is:


- Web application with a SIP over WebSocket cl= ient running in the web.

- The web user is provided with a conference SIP URI in which there
= are *already* 8 participants (5 of them emitting audio and video and 3
j= ust emitting audio).

- The user calls, from his webphone, to the giv= en URI to join the conference.



Let's imagine that the JS app knows the number of participa= nt in the conference.
Let's imagine my browser have mic and webcam.<= br>


QUESTION:

How can my browser join the conference without requiring SDP
renegotiation from the server and, at = the same time, being able to
send audio/video and receive audio/video fr= om others (different tracks
/ m=3Dlines)?




"SOLUT= IONS":



1)

I tell my browser to generate a SDP offer with:
=C2=A0 - 1 send/receive m=3Daudio line.
=C2=A0 - 7 recvonly m=3Daudio = line.
=C2=A0 - 1 send/only m=3Dvideo line.
=C2=A0 - 4 recvonly m=3Dvi= deo line.

(Obviously this is a joke)



2)

SDP seems to allow that the offer and the answer have= different number
of m lines (I'm not aware of that but I believe th= at SDP can do
"everything"). So my browser generates a SDP off= er with 1 m=3Daudio line
and 1 m=3Dvideo line, and the server replies with 8 m=3Daudio lines and 4m=3Dvideo lines.

Will my browser understand such a SDP answer with= more m lines than
its generated offer? I assume NOT.



3)<= br>
My browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo
line and th= e server too. And later the server sends re-INVITE with all
the m lines.=

Oppss, SDP renegotiation...




SDP is bad for WebRT= C. SDP is good for legacy symmetric communications
in which there is a single-track audio communication and, of course,
bot= h endpoints emit audio. But SDP is bad for modern RTC protocols in
which= an endpoint can emit tons of tracks to a single endpoint.


Do we= really want this for WebRTC 1.0 ?


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
____________________________= ___________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--0015175df19ef975ed04e2aa1e7a-- From silviapfeiffer1@gmail.com Mon Jul 29 15:53:12 2013 Return-Path: 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 7108511E813A for ; Mon, 29 Jul 2013 15:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 erlOn7-CfmGJ for ; Mon, 29 Jul 2013 15:53:11 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9E61611E8124 for ; Mon, 29 Jul 2013 15:53:11 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id fb19so1699681obc.38 for ; Mon, 29 Jul 2013 15:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=r4XSe7fxyC3OExREbyfpCpmbpk1Zuqya9zuJfPdKwhI=; b=SBzweVIBSLQ83ep554SCXKQj3O3ZgpVTKx4uofv1/rC/vMEn4vJVRHoShxblyh3Y3P hmh1wn3SUteXCq38SVojOHOaUfZN8juC6cHe4Y8Fngsi1icCSx5MCfQsQEjUjIP7rcHA p6qyTNEH5gom6C5SvdmcWSp0SXFkoVhzvzHWhXLqUV+tKCB0vhUSoVggbpHwqLKyJYSd ea0YWv9/uGHiL3Te6oeLPoizchLRpuRwC7Oo93fBExP5XsSJAoPW/XKlCXptvRnudJUO SiQyMzqNSMTTyQGfxiVPBkonGcxjnyi5tbaYOWShgxpFmqIJ8guaok29JEEMa2RS68Cm qrdA== X-Received: by 10.182.128.68 with SMTP id nm4mr19822926obb.56.1375138391126; Mon, 29 Jul 2013 15:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.173.106 with HTTP; Mon, 29 Jul 2013 15:52:51 -0700 (PDT) In-Reply-To: References: From: Silvia Pfeiffer Date: Tue, 30 Jul 2013 08:52:51 +1000 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 22:53:12 -0000 On Tue, Jul 30, 2013 at 3:31 AM, I=F1aki Baz Castillo wrote= : > Hi, I initiated a thread [*] about Plan-Unified and multiple m lines, > but it was moved to MMUSIC maillist (don't know why since it is about > WebRTC applications design): > > http://www.ietf.org/mail-archive/web/mmusic/current/msg11966.html > > Sorry for the cross-posting but at this point I'm a bit lost and do > not know which is the appropriate group for my concern. > > > > So my concern is: > > > - Web application with a SIP over WebSocket client running in the web. > > - The web user is provided with a conference SIP URI in which there > are *already* 8 participants (5 of them emitting audio and video and 3 > just emitting audio). > > - The user calls, from his webphone, to the given URI to join the confere= nce. > > > > Let's imagine that the JS app knows the number of participant in the conf= erence. > Let's imagine my browser have mic and webcam. > > > > QUESTION: > > How can my browser join the conference without requiring SDP > renegotiation from the server and, at the same time, being able to > send audio/video and receive audio/video from others (different tracks > / m=3Dlines)? > > > > > "SOLUTIONS": > > > > 1) > > I tell my browser to generate a SDP offer with: > > - 1 send/receive m=3Daudio line. > - 7 recvonly m=3Daudio line. > - 1 send/only m=3Dvideo line. > - 4 recvonly m=3Dvideo line. > > (Obviously this is a joke) Since you seem to be doing a full mesh and you seem to be wanting to receive from everyone and be able to talk back to everyone, wouldn't this need to be 8 different SDP offers in a full mesh network rather than one SDP offer with 13 different m-lines? I don't follow how each of the recipients would pick the right m-line for themselves... > 2) > > SDP seems to allow that the offer and the answer have different number > of m lines (I'm not aware of that but I believe that SDP can do > "everything"). So my browser generates a SDP offer with 1 m=3Daudio line > and 1 m=3Dvideo line, and the server replies with 8 m=3Daudio lines and 4 > m=3Dvideo lines. > > Will my browser understand such a SDP answer with more m lines than > its generated offer? I assume NOT. I'm don't understand SDP, but logic would tell me that it would send a single SDP offer with its own capabilities to each of the other 8 participants: m=3Daudio send/receive (not sure if it also needs m=3Dvideo, since it's not a video capable device= IIUC) > 3) > > My browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo > line and the server too. And later the server sends re-INVITE with all > the m lines. > > Oppss, SDP renegotiation... Yes, I would expect a negotiation to happen between each of the 8 current participants and the one new participant individually. It would end up in 8 O/A negotiations that should all end up with 5 m=3Daudio send/receive and 3 m=3Daudio receive-only (from the POV of the webphone. I'm taking a stab at this because I want to understand more about how it works, but I actually have no idea if I am correct. Please, somebody with SDP knowlege, clarify how this would actually work. I, too, am very curious. Thanks, Silvia. From ron@debian.org Mon Jul 29 16:15:05 2013 Return-Path: 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 3347621F8E2A for ; Mon, 29 Jul 2013 16:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] 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 f6xRzrnbzAWL for ; Mon, 29 Jul 2013 16:15:01 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id C44E421F8EC3 for ; Mon, 29 Jul 2013 16:15:00 -0700 (PDT) Received: from ppp121-45-106-39.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.106.39]) by ipmail04.adl6.internode.on.net with ESMTP; 30 Jul 2013 08:44:58 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id EC41D4F8F3 for ; Tue, 30 Jul 2013 08:44:56 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1WQJARWrG7cA for ; Tue, 30 Jul 2013 08:44:36 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 9D2474F902; Tue, 30 Jul 2013 08:44:36 +0930 (CST) Date: Tue, 30 Jul 2013 08:44:36 +0930 From: Ron To: rtcweb@ietf.org Message-ID: <20130729231436.GQ25981@audi.shelbyville.oz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 23:15:05 -0000 On Mon, Jul 29, 2013 at 07:31:55PM +0200, Iñaki Baz Castillo wrote: > Hi, I initiated a thread [*] about Plan-Unified and multiple m lines, > but it was moved to MMUSIC maillist (don't know why since it is about > WebRTC applications design): > > http://www.ietf.org/mail-archive/web/mmusic/current/msg11966.html > > Sorry for the cross-posting but at this point I'm a bit lost and do > not know which is the appropriate group for my concern. Have you tried a.r.k? From christer.holmberg@ericsson.com Mon Jul 29 20:52:54 2013 Return-Path: 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 670F311E81B4 for ; Mon, 29 Jul 2013 20:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.46 X-Spam-Level: X-Spam-Status: No, score=-5.46 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 zQLx2TzTp2Fr for ; Mon, 29 Jul 2013 20:52:49 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7219511E81B3 for ; Mon, 29 Jul 2013 20:52:48 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-97-51f7388d5b6f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E6.5F.05990.D8837F15; Tue, 30 Jul 2013 05:52:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Tue, 30 Jul 2013 05:52:45 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Bossiel thioriguel" Thread-Topic: [rtcweb] SDP is not suitable for WebRTC Thread-Index: AQHOjIHcZ/1hbOJS5UyRjSuEQ/tcvJl7zDIAgAABWACAAMllYA== Date: Tue, 30 Jul 2013 03:52:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4132BF@ESESSMB209.ericsson.se> References: <1375119910.76535.YahooMailNeo@web171302.mail.ir2.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4132BFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+JvrW6fxfdAgze/+Sym/jjOYjF9n41F 78cljBZr/7WzO7B4nGt4z+6xZMlPJo+j8/azerya/pA9gCWKyyYlNSezLLVI3y6BK6N1bgNr wYOFjBWTn01na2DcMZexi5GTQ0LAROLMvO9QtpjEhXvr2boYuTiEBA4zSsw4eZ0ZwlnCKDG7 Zx5QhoODTcBCovufNkiDiEC6xKSNH5hAbGaBCImLR16yg9jCQEO7F6xmhqgxldjw4TgThO0k cWdrLyuIzSKgKvFo3WKwel4BX4lvO35CLb7GKLHh5hWwizgFAiXO/jjMBmIzAl33/dQaqGXi Eh8OXmeGuFpAYsme81C2qMTLx/9YIWwlicYlT1gh6vMlXl7vYoZYJihxcuYTlgmMorOQjJqF pGwWkrJZQC8zC2hKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWM7LmJmTnp5UabGIHRd3DL b9UdjHfOiRxilOZgURLn3ax3JlBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo07Zzmkv9nJx B7Ac9tczYXup9Uf727UMm+1tcQGWl8v32zu9t1sVJ/flSEPoqjDP4zqTpzd2ZzrEBMS33Hxf lhDYIXV7qR2D0Fb3LiGjkG/Fs+/M5km+vMvszsWuL7WyX7KLls2Urm96xGB1I9FU6Yncwmru CzN0r0ZNnyYWIa/J1N/z8V+QEktxRqKhFnNRcSIAAq6Hk4wCAAA= Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 03:52:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4132BFESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgd2FzIG5vdCB3cm9uZywgYnV0IEkgd2FzIG1heWJlIHVuY2xlYXIuIEkgbWVhbnQg dGhhdCBlYWNoIGVudGl0eSB3b3VsZCBvZmZlciBpdOKAmXMgbS0gbGluZXMgYXMgcGFydCBvZiBz ZXBhcmF0ZSBPZmZlci9BbnN3ZXIgdHJhbnNhY3Rpb25zLiBJdCBJUyBhbGxvd2VkIHRvIGFkZCBt LSBsaW5lcyBpbiBhIHN1YnNlcXVlbnQgT2ZmZXIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN CkzDpGhldHTDpGrDpDogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRd DQpMw6RoZXRldHR5OiAyOS4gaGVpbsOka3V1dGEgMjAxMyAyMDo1MA0KVmFzdGFhbm90dGFqYTog Qm9zc2llbCB0aGlvcmlndWVsDQpLb3BpbzogcHVibGljLXdlYnJ0Y0B3My5vcmc7IHJ0Y3dlYkBp ZXRmLm9yZw0KQWloZTogUmU6IFtydGN3ZWJdIFNEUCBpcyBub3Qgc3VpdGFibGUgZm9yIFdlYlJU Qw0KDQoNClRoYW5rcyBhIGxvdCBmb3IgY2xhcmlmeWluZyBpdC4gU28gQ2hyaXN0ZXIgd2FzIHdy b25nIDspDQoNCkFuZCBpdCBtYWtlcyBteSBzY2VuYXJpbyBldmVuIHdvcnNlLiBJIHJlYWxseSBo b3BlIHNvbWV0aGluZyB3aWxsIGhhcHBlbiBhbmQgV2ViUlRDIHdpbGwgZ2V0IHJpZCBvZiBTRFAu Li4NCg0KLS0NCknDsWFraSBCYXogQ2FzdGlsbG8NCjxpYmNAYWxpYXgubmV0PG1haWx0bzppYmNA YWxpYXgubmV0Pj4NCkVsIDI5LzA3LzIwMTMgMTk6NDUsICJCb3NzaWVsIHRoaW9yaWd1ZWwiIDxi b3NzaWVsQHlhaG9vLmZyPG1haWx0bzpib3NzaWVsQHlhaG9vLmZyPj4gZXNjcmliacOzOg0KWW91 IHNhaWQ6ICIyKQ0KDQpTRFAgc2VlbXMgdG8gYWxsb3cgdGhhdCB0aGUgb2ZmZXIgYW5kIHRoZSBh bnN3ZXIgaGF2ZSBkaWZmZXJlbnQgbnVtYmVyDQpvZiBtIGxpbmVzICINCg0KTm8gYXQgYWxsOg0K UkZDIDMyNjQ6DQpGb3IgZWFjaCAibT0iIGxpbmUgaW4gdGhlIG9mZmVyLCB0aGVyZSBNVVNUIGJl IGEgY29ycmVzcG9uZGluZyAibT0iDQoNCiAgIGxpbmUgaW4gdGhlIGFuc3dlci4gIFRoZSBhbnN3 ZXIgTVVTVCBjb250YWluIGV4YWN0bHkgdGhlIHNhbWUgbnVtYmVyDQoNCiAgIG9mICJtPSIgbGlu ZXMgYXMgdGhlIG9mZmVyLiAgVGhpcyBhbGxvd3MgZm9yIHN0cmVhbXMgdG8gYmUgbWF0Y2hlZCB1 cA0KDQogICBiYXNlZCBvbiB0aGVpciBvcmRlci4gIFRoaXMgaW1wbGllcyB0aGF0IGlmIHRoZSBv ZmZlciBjb250YWluZWQgemVybw0KDQogICAibT0iIGxpbmVzLCB0aGUgYW5zd2VyIE1VU1QgY29u dGFpbiB6ZXJvICJtPSIgbGluZXMuDQoNCk1hbWFkb3UuDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpEZSA6IEnDsWFraSBCYXogQ2FzdGlsbG8gPGliY0BhbGlheC5uZXQ8bWFp bHRvOmliY0BhbGlheC5uZXQ+Pg0Kw4AgOiAicnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJA aWV0Zi5vcmc+IiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+PjsgInB1 YmxpYy13ZWJydGNAdzMub3JnPG1haWx0bzpwdWJsaWMtd2VicnRjQHczLm9yZz4iIDxwdWJsaWMt d2VicnRjQHczLm9yZzxtYWlsdG86cHVibGljLXdlYnJ0Y0B3My5vcmc+Pg0KRW52b3nDqSBsZSA6 IEx1bmRpIDI5IGp1aWxsZXQgMjAxMyAxOWgzMQ0KT2JqZXQgOiBbcnRjd2ViXSBTRFAgaXMgbm90 IHN1aXRhYmxlIGZvciBXZWJSVEMNCg0KSGksIEkgaW5pdGlhdGVkIGEgdGhyZWFkIFsqXSBhYm91 dCBQbGFuLVVuaWZpZWQgYW5kIG11bHRpcGxlIG0gbGluZXMsDQpidXQgaXQgd2FzIG1vdmVkIHRv IE1NVVNJQyBtYWlsbGlzdCAoZG9uJ3Qga25vdyB3aHkgc2luY2UgaXQgaXMgYWJvdXQNCldlYlJU QyBhcHBsaWNhdGlvbnMgZGVzaWduKToNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL21tdXNpYy9jdXJyZW50L21zZzExOTY2Lmh0bWwNCg0KU29ycnkgZm9yIHRoZSBjcm9z cy1wb3N0aW5nIGJ1dCBhdCB0aGlzIHBvaW50IEknbSBhIGJpdCBsb3N0IGFuZCBkbw0Kbm90IGtu b3cgd2hpY2ggaXMgdGhlIGFwcHJvcHJpYXRlIGdyb3VwIGZvciBteSBjb25jZXJuLg0KDQoNCg0K U28gbXkgY29uY2VybiBpczoNCg0KDQotIFdlYiBhcHBsaWNhdGlvbiB3aXRoIGEgU0lQIG92ZXIg V2ViU29ja2V0IGNsaWVudCBydW5uaW5nIGluIHRoZSB3ZWIuDQoNCi0gVGhlIHdlYiB1c2VyIGlz IHByb3ZpZGVkIHdpdGggYSBjb25mZXJlbmNlIFNJUCBVUkkgaW4gd2hpY2ggdGhlcmUNCmFyZSAq YWxyZWFkeSogOCBwYXJ0aWNpcGFudHMgKDUgb2YgdGhlbSBlbWl0dGluZyBhdWRpbyBhbmQgdmlk ZW8gYW5kIDMNCmp1c3QgZW1pdHRpbmcgYXVkaW8pLg0KDQotIFRoZSB1c2VyIGNhbGxzLCBmcm9t IGhpcyB3ZWJwaG9uZSwgdG8gdGhlIGdpdmVuIFVSSSB0byBqb2luIHRoZSBjb25mZXJlbmNlLg0K DQoNCg0KTGV0J3MgaW1hZ2luZSB0aGF0IHRoZSBKUyBhcHAga25vd3MgdGhlIG51bWJlciBvZiBw YXJ0aWNpcGFudCBpbiB0aGUgY29uZmVyZW5jZS4NCkxldCdzIGltYWdpbmUgbXkgYnJvd3NlciBo YXZlIG1pYyBhbmQgd2ViY2FtLg0KDQoNCg0KUVVFU1RJT046DQoNCkhvdyBjYW4gbXkgYnJvd3Nl ciBqb2luIHRoZSBjb25mZXJlbmNlIHdpdGhvdXQgcmVxdWlyaW5nIFNEUA0KcmVuZWdvdGlhdGlv biBmcm9tIHRoZSBzZXJ2ZXIgYW5kLCBhdCB0aGUgc2FtZSB0aW1lLCBiZWluZyBhYmxlIHRvDQpz ZW5kIGF1ZGlvL3ZpZGVvIGFuZCByZWNlaXZlIGF1ZGlvL3ZpZGVvIGZyb20gb3RoZXJzIChkaWZm ZXJlbnQgdHJhY2tzDQovIG09bGluZXMpPw0KDQoNCg0KDQoiU09MVVRJT05TIjoNCg0KDQoNCjEp DQoNCkkgdGVsbCBteSBicm93c2VyIHRvIGdlbmVyYXRlIGEgU0RQIG9mZmVyIHdpdGg6DQoNCiAg LSAxIHNlbmQvcmVjZWl2ZSBtPWF1ZGlvIGxpbmUuDQogIC0gNyByZWN2b25seSBtPWF1ZGlvIGxp bmUuDQogIC0gMSBzZW5kL29ubHkgbT12aWRlbyBsaW5lLg0KICAtIDQgcmVjdm9ubHkgbT12aWRl byBsaW5lLg0KDQooT2J2aW91c2x5IHRoaXMgaXMgYSBqb2tlKQ0KDQoNCg0KMikNCg0KU0RQIHNl ZW1zIHRvIGFsbG93IHRoYXQgdGhlIG9mZmVyIGFuZCB0aGUgYW5zd2VyIGhhdmUgZGlmZmVyZW50 IG51bWJlcg0Kb2YgbSBsaW5lcyAoSSdtIG5vdCBhd2FyZSBvZiB0aGF0IGJ1dCBJIGJlbGlldmUg dGhhdCBTRFAgY2FuIGRvDQoiZXZlcnl0aGluZyIpLiBTbyBteSBicm93c2VyIGdlbmVyYXRlcyBh IFNEUCBvZmZlciB3aXRoIDEgbT1hdWRpbyBsaW5lDQphbmQgMSBtPXZpZGVvIGxpbmUsIGFuZCB0 aGUgc2VydmVyIHJlcGxpZXMgd2l0aCA4IG09YXVkaW8gbGluZXMgYW5kIDQNCm09dmlkZW8gbGlu ZXMuDQoNCldpbGwgbXkgYnJvd3NlciB1bmRlcnN0YW5kIHN1Y2ggYSBTRFAgYW5zd2VyIHdpdGgg bW9yZSBtIGxpbmVzIHRoYW4NCml0cyBnZW5lcmF0ZWQgb2ZmZXI/IEkgYXNzdW1lIE5PVC4NCg0K DQoNCjMpDQoNCk15IGJyb3dzZXIgZ2VuZXJhdGVzIGEgU0RQIG9mZmVyIHdpdGggMSBtPWF1ZGlv IGxpbmUgYW5kIDEgbT12aWRlbw0KbGluZSBhbmQgdGhlIHNlcnZlciB0b28uIEFuZCBsYXRlciB0 aGUgc2VydmVyIHNlbmRzIHJlLUlOVklURSB3aXRoIGFsbA0KdGhlIG0gbGluZXMuDQoNCk9wcHNz LCBTRFAgcmVuZWdvdGlhdGlvbi4uLg0KDQoNCg0KDQpTRFAgaXMgYmFkIGZvciBXZWJSVEMuIFNE UCBpcyBnb29kIGZvciBsZWdhY3kgc3ltbWV0cmljIGNvbW11bmljYXRpb25zDQppbiB3aGljaCB0 aGVyZSBpcyBhIHNpbmdsZS10cmFjayBhdWRpbyBjb21tdW5pY2F0aW9uIGFuZCwgb2YgY291cnNl LA0KYm90aCBlbmRwb2ludHMgZW1pdCBhdWRpby4gQnV0IFNEUCBpcyBiYWQgZm9yIG1vZGVybiBS VEMgcHJvdG9jb2xzIGluDQp3aGljaCBhbiBlbmRwb2ludCBjYW4gZW1pdCB0b25zIG9mIHRyYWNr cyB0byBhIHNpbmdsZSBlbmRwb2ludC4NCg0KDQpEbyB3ZSByZWFsbHkgd2FudCB0aGlzIGZvciBX ZWJSVEMgMS4wID8NCg0KDQotLQ0KScOxYWtpIEJheiBDYXN0aWxsbw0KPGliY0BhbGlheC5uZXQ8 bWFpbHRvOmliY0BhbGlheC5uZXQ+Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg0K --_000_7594FB04B1934943A5C02806D1A2204B1C4132BFESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwtZXNpbXVvdG9pbHR1IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiU2VsaXRldGVrc3Rp IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1M LWVzaW11b3RvaWx0dUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwtZXNpbXVvdG9pbHR1IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazpIVE1MLWVzaW11 b3RvaWx0dTsNCglmb250LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6Rkk7fQ0Kc3Bhbi5TaGtwb3N0aXR5eWxpMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uU2VsaXRldGVrc3RpQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiU2Vs aXRldGVrc3RpIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azpTZWxpdGV0ZWtzdGk7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1z by1mYXJlYXN0LWxhbmd1YWdlOkZJO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd2FzIG5vdCB3cm9u ZywgYnV0IEkgd2FzIG1heWJlIHVuY2xlYXIuIEkgbWVhbnQgdGhhdCBlYWNoIGVudGl0eSB3b3Vs ZCBvZmZlciBpdOKAmXMgbS0gbGluZXMgYXMgcGFydCBvZiBzZXBhcmF0ZSBPZmZlci9BbnN3ZXIg dHJhbnNhY3Rpb25zLiBJdA0KIElTIGFsbG93ZWQgdG8gYWRkIG0tIGxpbmVzIGluIGEgc3Vic2Vx dWVudCBPZmZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5M w6RoZXR0w6Rqw6Q6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEnDsWFr aSBCYXogQ2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgubmV0XQ0KPGJyPg0KPGI+TMOkaGV0ZXR0 eTo8L2I+IDI5LiBoZWluw6RrdXV0YSAyMDEzIDIwOjUwPGJyPg0KPGI+VmFzdGFhbm90dGFqYTo8 L2I+IEJvc3NpZWwgdGhpb3JpZ3VlbDxicj4NCjxiPktvcGlvOjwvYj4gcHVibGljLXdlYnJ0Y0B3 My5vcmc7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPkFpaGU6PC9iPiBSZTogW3J0Y3dlYl0gU0RQ IGlzIG5vdCBzdWl0YWJsZSBmb3IgV2ViUlRDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5UaGFua3MgYSBsb3QgZm9y IGNsYXJpZnlpbmcgaXQuIFNvIENocmlzdGVyIHdhcyB3cm9uZyA7KTxvOnA+PC9vOnA+PC9wPg0K PHA+QW5kIGl0IG1ha2VzIG15IHNjZW5hcmlvIGV2ZW4gd29yc2UuIEkgcmVhbGx5IGhvcGUgc29t ZXRoaW5nIHdpbGwgaGFwcGVuIGFuZCBXZWJSVEMgd2lsbCBnZXQgcmlkIG9mIFNEUC4uLg0KPG86 cD48L286cD48L3A+DQo8cD4tLTxicj4NCknDsWFraSBCYXogQ2FzdGlsbG88YnI+DQombHQ7PGEg aHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiPmliY0BhbGlheC5uZXQ8L2E+Jmd0OzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVsIDI5LzA3LzIwMTMgMTk6NDUs ICZxdW90O0Jvc3NpZWwgdGhpb3JpZ3VlbCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJvc3Np ZWxAeWFob28uZnIiPmJvc3NpZWxAeWFob28uZnI8L2E+Jmd0OyBlc2NyaWJpw7M6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3Ugc2Fp ZDogJnF1b3Q7Mik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KU0RQIHNlZW1zIHRvIGFsbG93IHRoYXQgdGhlIG9mZmVyIGFuZCB0aGUgYW5zd2VyIGhh dmUgZGlmZmVyZW50IG51bWJlcjxicj4NCm9mIG0gbGluZXMmbmJzcDsmcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBhdCBhbGw6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SRkMgMzI2NDo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBlYWNoICZxdW90O209 JnF1b3Q7IGxpbmUgaW4gdGhlIG9mZmVyLCB0aGVyZSBNVVNUIGJlIGEgY29ycmVzcG9uZGluZyAm cXVvdDttPSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOyZuYnNwOyBs aW5lIGluIHRoZSBhbnN3ZXIuJm5ic3A7IFRoZSBhbnN3ZXIgTVVTVCBjb250YWluIGV4YWN0bHkg dGhlIHNhbWUgbnVtYmVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG9mICZx dW90O209JnF1b3Q7IGxpbmVzIGFzIHRoZSBvZmZlci4mbmJzcDsgVGhpcyBhbGxvd3MgZm9yIHN0 cmVhbXMgdG8gYmUgbWF0Y2hlZCB1cDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBiYXNlZCBvbiB0aGVpciBvcmRlci4mbmJzcDsgVGhpcyBpbXBsaWVzIHRoYXQgaWYgdGhlIG9m ZmVyIGNvbnRhaW5lZCB6ZXJvPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICZx dW90O209JnF1b3Q7IGxpbmVzLCB0aGUgYW5zd2VyIE1VU1QgY29udGFpbiB6ZXJvICZxdW90O209 JnF1b3Q7IGxpbmVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+TWFtYWRvdS48bzpwPjwvbzpwPjwvcHJlPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBh bGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJw7Fha2kgQmF6IENhc3RpbGxvICZsdDs8 YSBocmVmPSJtYWlsdG86aWJjQGFsaWF4Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmliY0BhbGlheC5u ZXQ8L2E+Jmd0Ozxicj4NCjxiPsOAJm5ic3A7OjwvYj4gJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3 ZWJAaWV0Zi5vcmc8L2E+Jmd0OzsgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnB1YmxpYy13ZWJydGNA dzMub3JnIiB0YXJnZXQ9Il9ibGFuayI+cHVibGljLXdlYnJ0Y0B3My5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86cHVibGljLXdlYnJ0Y0B3My5vcmciIHRhcmdldD0iX2JsYW5rIj5w dWJsaWMtd2VicnRjQHczLm9yZzwvYT4mZ3Q7DQo8YnI+DQo8Yj5FbnZvecOpIGxlIDo8L2I+IEx1 bmRpIDI5IGp1aWxsZXQgMjAxMyAxOWgzMTxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW3J0Y3dl Yl0gU0RQIGlzIG5vdCBzdWl0YWJsZSBmb3IgV2ViUlRDPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpIaSwgSSBpbml0aWF0ZWQgYSB0aHJlYWQgWypdIGFib3V0IFBsYW4tVW5p ZmllZCBhbmQgbXVsdGlwbGUgbSBsaW5lcyw8YnI+DQpidXQgaXQgd2FzIG1vdmVkIHRvIE1NVVNJ QyBtYWlsbGlzdCAoZG9uJ3Qga25vdyB3aHkgc2luY2UgaXQgaXMgYWJvdXQ8YnI+DQpXZWJSVEMg YXBwbGljYXRpb25zIGRlc2lnbik6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50L21zZzExOTY2Lmh0bWwiIHRhcmdl dD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbW11c2ljL2N1 cnJlbnQvbXNnMTE5NjYuaHRtbDwvYT48YnI+DQo8YnI+DQpTb3JyeSBmb3IgdGhlIGNyb3NzLXBv c3RpbmcgYnV0IGF0IHRoaXMgcG9pbnQgSSdtIGEgYml0IGxvc3QgYW5kIGRvPGJyPg0Kbm90IGtu b3cgd2hpY2ggaXMgdGhlIGFwcHJvcHJpYXRlIGdyb3VwIGZvciBteSBjb25jZXJuLjxicj4NCjxi cj4NCjxicj4NCjxicj4NClNvIG15IGNvbmNlcm4gaXM6PGJyPg0KPGJyPg0KPGJyPg0KLSBXZWIg YXBwbGljYXRpb24gd2l0aCBhIFNJUCBvdmVyIFdlYlNvY2tldCBjbGllbnQgcnVubmluZyBpbiB0 aGUgd2ViLjxicj4NCjxicj4NCi0gVGhlIHdlYiB1c2VyIGlzIHByb3ZpZGVkIHdpdGggYSBjb25m ZXJlbmNlIFNJUCBVUkkgaW4gd2hpY2ggdGhlcmU8YnI+DQphcmUgKmFscmVhZHkqIDggcGFydGlj aXBhbnRzICg1IG9mIHRoZW0gZW1pdHRpbmcgYXVkaW8gYW5kIHZpZGVvIGFuZCAzPGJyPg0KanVz dCBlbWl0dGluZyBhdWRpbykuPGJyPg0KPGJyPg0KLSBUaGUgdXNlciBjYWxscywgZnJvbSBoaXMg d2VicGhvbmUsIHRvIHRoZSBnaXZlbiBVUkkgdG8gam9pbiB0aGUgY29uZmVyZW5jZS48YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQpMZXQncyBpbWFnaW5lIHRoYXQgdGhlIEpTIGFwcCBrbm93cyB0aGUg bnVtYmVyIG9mIHBhcnRpY2lwYW50IGluIHRoZSBjb25mZXJlbmNlLjxicj4NCkxldCdzIGltYWdp bmUgbXkgYnJvd3NlciBoYXZlIG1pYyBhbmQgd2ViY2FtLjxicj4NCjxicj4NCjxicj4NCjxicj4N ClFVRVNUSU9OOjxicj4NCjxicj4NCkhvdyBjYW4gbXkgYnJvd3NlciBqb2luIHRoZSBjb25mZXJl bmNlIHdpdGhvdXQgcmVxdWlyaW5nIFNEUDxicj4NCnJlbmVnb3RpYXRpb24gZnJvbSB0aGUgc2Vy dmVyIGFuZCwgYXQgdGhlIHNhbWUgdGltZSwgYmVpbmcgYWJsZSB0bzxicj4NCnNlbmQgYXVkaW8v dmlkZW8gYW5kIHJlY2VpdmUgYXVkaW8vdmlkZW8gZnJvbSBvdGhlcnMgKGRpZmZlcmVudCB0cmFj a3M8YnI+DQovIG09bGluZXMpPzxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZxdW90O1NP TFVUSU9OUyZxdW90Ozo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQoxKTxicj4NCjxicj4NCkkgdGVs bCBteSBicm93c2VyIHRvIGdlbmVyYXRlIGEgU0RQIG9mZmVyIHdpdGg6PGJyPg0KPGJyPg0KJm5i c3A7IC0gMSBzZW5kL3JlY2VpdmUgbT1hdWRpbyBsaW5lLjxicj4NCiZuYnNwOyAtIDcgcmVjdm9u bHkgbT1hdWRpbyBsaW5lLjxicj4NCiZuYnNwOyAtIDEgc2VuZC9vbmx5IG09dmlkZW8gbGluZS48 YnI+DQombmJzcDsgLSA0IHJlY3Zvbmx5IG09dmlkZW8gbGluZS48YnI+DQo8YnI+DQooT2J2aW91 c2x5IHRoaXMgaXMgYSBqb2tlKTxicj4NCjxicj4NCjxicj4NCjxicj4NCjIpPGJyPg0KPGJyPg0K U0RQIHNlZW1zIHRvIGFsbG93IHRoYXQgdGhlIG9mZmVyIGFuZCB0aGUgYW5zd2VyIGhhdmUgZGlm ZmVyZW50IG51bWJlcjxicj4NCm9mIG0gbGluZXMgKEknbSBub3QgYXdhcmUgb2YgdGhhdCBidXQg SSBiZWxpZXZlIHRoYXQgU0RQIGNhbiBkbzxicj4NCiZxdW90O2V2ZXJ5dGhpbmcmcXVvdDspLiBT byBteSBicm93c2VyIGdlbmVyYXRlcyBhIFNEUCBvZmZlciB3aXRoIDEgbT1hdWRpbyBsaW5lPGJy Pg0KYW5kIDEgbT12aWRlbyBsaW5lLCBhbmQgdGhlIHNlcnZlciByZXBsaWVzIHdpdGggOCBtPWF1 ZGlvIGxpbmVzIGFuZCA0PGJyPg0KbT12aWRlbyBsaW5lcy48YnI+DQo8YnI+DQpXaWxsIG15IGJy b3dzZXIgdW5kZXJzdGFuZCBzdWNoIGEgU0RQIGFuc3dlciB3aXRoIG1vcmUgbSBsaW5lcyB0aGFu PGJyPg0KaXRzIGdlbmVyYXRlZCBvZmZlcj8gSSBhc3N1bWUgTk9ULjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjMpPGJyPg0KPGJyPg0KTXkgYnJvd3NlciBnZW5lcmF0ZXMgYSBTRFAgb2ZmZXIgd2l0 aCAxIG09YXVkaW8gbGluZSBhbmQgMSBtPXZpZGVvPGJyPg0KbGluZSBhbmQgdGhlIHNlcnZlciB0 b28uIEFuZCBsYXRlciB0aGUgc2VydmVyIHNlbmRzIHJlLUlOVklURSB3aXRoIGFsbDxicj4NCnRo ZSBtIGxpbmVzLjxicj4NCjxicj4NCk9wcHNzLCBTRFAgcmVuZWdvdGlhdGlvbi4uLjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NClNEUCBpcyBiYWQgZm9yIFdlYlJUQy4gU0RQIGlzIGdvb2Qg Zm9yIGxlZ2FjeSBzeW1tZXRyaWMgY29tbXVuaWNhdGlvbnM8YnI+DQppbiB3aGljaCB0aGVyZSBp cyBhIHNpbmdsZS10cmFjayBhdWRpbyBjb21tdW5pY2F0aW9uIGFuZCwgb2YgY291cnNlLDxicj4N CmJvdGggZW5kcG9pbnRzIGVtaXQgYXVkaW8uIEJ1dCBTRFAgaXMgYmFkIGZvciBtb2Rlcm4gUlRD IHByb3RvY29scyBpbjxicj4NCndoaWNoIGFuIGVuZHBvaW50IGNhbiBlbWl0IHRvbnMgb2YgdHJh Y2tzIHRvIGEgc2luZ2xlIGVuZHBvaW50Ljxicj4NCjxicj4NCjxicj4NCkRvIHdlIHJlYWxseSB3 YW50IHRoaXMgZm9yIFdlYlJUQyAxLjAgPzxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCknDsWFr aSBCYXogQ2FzdGlsbG88YnI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiIHRh cmdldD0iX2JsYW5rIj5pYmNAYWxpYXgubmV0PC9hPiZndDs8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRj d2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1C4132BFESESSMB209erics_-- From ibc@aliax.net Tue Jul 30 00:46:26 2013 Return-Path: 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 C33ED11E81D0 for ; Tue, 30 Jul 2013 00:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 OGjVgLXOwYnq for ; Tue, 30 Jul 2013 00:46:20 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5A211E81CA for ; Tue, 30 Jul 2013 00:46:20 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id k5so2426652qej.30 for ; Tue, 30 Jul 2013 00:46:19 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=LrodUu7U+Fqlh6dvDjjQ2cWJod/MdCOVeyIrbltN0oQ=; b=DcqQH3h3H891ne8GO7ZEZqBg6b03VjQ8w6MvNGPBH3zmne8cMGiK3OeIjQ7+y7yFZn zHmiKocAxv9YGEb7EiL/NECd0pT+GG1ZFObEQdBOiIpTyLrB187ey8IGyW0ITrqFmZ0Q amZcctCyxztVfiag6SBifKBCElTrbZqq/sLfS/24jfBGURB4/EsKe8cu85gu05C5tDCf 1rXsYMyLM5QGqjR1ldWyeYDERy0ojdvrWpApnpKC+BsYwtLLBR8rsDYUR8BZyc57e4H4 4CHVyF0sDJurEY1avc7OQjWEYBMSnRlDOABOQ2UXliISzlp/dfuYrkoNrX7QgkcrBPmc I6WA== X-Received: by 10.224.28.137 with SMTP id m9mr16641218qac.22.1375170379779; Tue, 30 Jul 2013 00:46:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 30 Jul 2013 00:45:59 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Jul 2013 09:45:59 +0200 Message-ID: To: Silvia Pfeiffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmfxKSZ5+eRnvv/LjgzeftmrJIhq6IHDDbKd2Xh4+WriNdHq7z+v3JEJ5Hp8W7z+Xjycwla Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 07:46:26 -0000 2013/7/30 Silvia Pfeiffer : > Since you seem to be doing a full mesh and you seem to be wanting to > receive from everyone and be able to talk back to everyone, wouldn't > this need to be 8 different SDP offers in a full mesh network rather > than one SDP offer with 13 different m-lines? I don't follow how each > of the recipients would pick the right m-line for themselves... Silvia, I don't feel I am doing a full mesh, but something really common, which is: - I contact, from my browser, to a conference server in which there is an active conference with N participants. - I provide my audio and video tracks to the conference server. - The server provides me with N audio/video tracks belonging to N participa= nts. - I don't want to do a second SDP O/A round trip. Please, note that my browser has a signaling and a media session with the conference server. This is, the endpoints are my browser and the conference server. The fact that the conference server acts as a mixer by joining all the participants changes nothing. The browser establishes a single RTC session with the server. This is not an exotic scenario at all. And no, I do not want to send 8 different SDP offers since I will mantain just a single RTC session (with the conference server). All the participants do the same, and the conference server is responsible of taking all the tracks from participants and send them to all the participants (via separate tracks). I would like to hear the opinion of those in favour of SDP for WebRTC, since what I am clearly stating is that SDP and Plan-Unified is *bad* for this common scenario. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Jul 30 00:48:56 2013 Return-Path: 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 87E4211E80F4 for ; Tue, 30 Jul 2013 00:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 KqOeYF-LPwJD for ; Tue, 30 Jul 2013 00:48:51 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5378011E81D4 for ; Tue, 30 Jul 2013 00:48:51 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id j10so1019602qcx.39 for ; Tue, 30 Jul 2013 00:48:49 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=znSIqnWZU7zzIamj/5pdNawPjEnErNxtHrxKwsu3OG4=; b=erSaKlgMPL7hQ+C2ZVidiiwrdKwqSsav1yyVeXY+KIUV2k6eaObWV3tb+ASuoN3cjL 1ea3omnkzJrS6Hrfvd96DcYi0PCzx7IdkM/tIreQCLjM1b2RCwsfjm08PxhiUPZdUja4 rFgV3GxhckDr3hWd1lBL356nTeAegp4TAncumWl1zQ9uYsjFHeLipXqqU8Hc7IrlZyue m/nchrdivAQz4ZtdVVfPEss5h+WSIVKYL/jS6+eAzRoaUDELjUakD4cYya7tz6+00bXW EX4vhqNex2EmT+ap7G8EmVDY2jpzctqhiyLvMIqj5N8VH8UdCo/cOF6NYsuxii8mH9vJ sl8A== X-Received: by 10.224.182.79 with SMTP id cb15mr77511384qab.48.1375170529741; Tue, 30 Jul 2013 00:48:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 30 Jul 2013 00:48:29 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4132BF@ESESSMB209.ericsson.se> References: <1375119910.76535.YahooMailNeo@web171302.mail.ir2.yahoo.com> <7594FB04B1934943A5C02806D1A2204B1C4132BF@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Jul 2013 09:48:29 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlCu321uVDejVqn/kspVPLpz4l1gCXwxvMcN81CLD5cPwqTTKrL/k0zgQPG83yXmC7JNLhW Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 07:48:56 -0000 2013/7/30 Christer Holmberg : > I was not wrong, but I was maybe unclear. OK > I meant that each entity would > offer it=E2=80=99s m- lines as part of separate Offer/Answer transactions= . It IS > allowed to add m- lines in a subsequent Offer. Yes, but that seems 100% unnecessary. The only we need is that peer-A tells peer-B about its tracks and peer-B tells peer-A about its tracks. We don't have that with SDP. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Jul 30 00:56:43 2013 Return-Path: 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 3D16D21E80BD for ; Tue, 30 Jul 2013 00:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.767 X-Spam-Level: X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 oNTmsxuauIoj for ; Tue, 30 Jul 2013 00:56:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5518C11E80F4 for ; Tue, 30 Jul 2013 00:56:29 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-ee-51f771a7f2fc Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 06.16.05990.7A177F15; Tue, 30 Jul 2013 09:56:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Tue, 30 Jul 2013 09:56:23 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] SDP is not suitable for WebRTC Thread-Index: AQHOjIHcZ/1hbOJS5UyRjSuEQ/tcvJl7zDIAgAABWACAAMllYIAAIOKAgAAjYvA= Date: Tue, 30 Jul 2013 07:56:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4135FD@ESESSMB209.ericsson.se> References: <1375119910.76535.YahooMailNeo@web171302.mail.ir2.yahoo.com> <7594FB04B1934943A5C02806D1A2204B1C4132BF@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvre6Kwu+BBk0beC2m/jjOYjF9n41F 78cljBZr/7WzO7B4nGt4z+6xZMlPJo+j8/azerya/pA9gCWKyyYlNSezLLVI3y6BK6Ovt4O9 4ARLxc8nz1gbGHewdDFycEgImEgcWMPVxcgJZIpJXLi3ng3EFhI4zCjx+ox2FyMXkL2EUeLN rC9sIPVsAhYS3f+0QWpEBGwk/l24wA5iMwvUS9w9/JQFxBYGGtm9YDUzRI2pxIYPx5kgbD+J ozt2gs1nEVCVOPvrEFg9r4CvxPdPXUwQux4ySZx5O4URJMEpECjxaVcbWAMj0HHfT61hglgm LvHh4HVmiKMFJJbsOQ9li0q8fPyPFcJWkvix4RLYj8wCmhLrd+lDtCpKTOl+yA6xV1Di5Mwn LBMYxWYhmToLoWMWko5ZSDoWMLKsYmTPTczMSS832sQIjKGDW36r7mC8c07kEKM0B4uSOO9m vTOBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjLQvkT3xp8v3k3ysT1RrLXxmSzax33i2fU li5uU+14/mvWooqngnscPBalN7LtCr/M6XTlZ+arf1uk1qmGxl498Mnx9RyDKf6CiVpPA4SX +FxkOyHwX1g9/fOSKRYid62939vNkXX+Js9yUev/ibyXQlMCtX5dO2kkm2uTuz3m8rmC4FXM N9YrsRRnJBpqMRcVJwIAgZaBim8CAAA= Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 07:56:44 -0000 DQo+PiBJIG1lYW50IHRoYXQgZWFjaCBlbnRpdHkgd291bGQNCj4+IG9mZmVyIGl04oCZcyBtLSBs aW5lcyBhcyBwYXJ0IG9mIHNlcGFyYXRlIE9mZmVyL0Fuc3dlciB0cmFuc2FjdGlvbnMuIEl0IA0K Pj4gSVMgYWxsb3dlZCB0byBhZGQgbS0gbGluZXMgaW4gYSBzdWJzZXF1ZW50IE9mZmVyLg0KPg0K PiBZZXMsIGJ1dCB0aGF0IHNlZW1zIDEwMCUgdW5uZWNlc3NhcnkuIFRoZSBvbmx5IHdlIG5lZWQg aXMgdGhhdCBwZWVyLUEgdGVsbHMgcGVlci1CIGFib3V0IGl0cyB0cmFja3MgYW5kIHBlZXItQiB0 ZWxscyBwZWVyLUEgYWJvdXQgaXRzIHRyYWNrcy4gV2UgZG9uJ3QgaGF2ZSB0aGF0IHdpdGggU0RQ Lg0KDQpXZWxsLCB0aGUgcGVlcnMgaGF2ZSB0byB1c2UgU09NRVRISU5HIHRvIGRvIHRoYXQuDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From ibc@aliax.net Tue Jul 30 01:01:43 2013 Return-Path: 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 6522321E80BF for ; Tue, 30 Jul 2013 01:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 eokNCF1y8giu for ; Tue, 30 Jul 2013 01:01:34 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C977A21E80C4 for ; Tue, 30 Jul 2013 01:01:31 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id a1so857438qcx.31 for ; Tue, 30 Jul 2013 01:01:31 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=otKA+3gwZKEk1aCGtelGWkEQBt4yfQzTEde2Sp7/tyk=; b=nnbtHdrLEJzlpRSXAgG+x+rz1iUEg/yHjAjF9iLcaNbnJASXl4bqcYJDzK1vN5Y0b9 nzR4jcvOoirZg4hqhLB9gAPhs3FvBE4ecfuRVQxiQP/HeMDjHSOzS7TYa1DqDdJqNSUq jOrQqa3EYa+pZzVp2Ror2AWdHyDcM2LqD3okG6F2C9Oao2AWxguScFlAhwohfnazJ/9q H7obl5WvHqYSE0rClblPagIbJZqUSyPbX7w5s7QbQU8wyGk7URzTKxkKfDJmcIYmtwRw jAhR7m1cyZQ9525SAqJ3YvfryrdmJlefqidBqVA2YgEtnJvf6uG9JnrVJBqSpLtELND1 N8nw== X-Received: by 10.224.28.137 with SMTP id m9mr16682541qac.22.1375171291244; Tue, 30 Jul 2013 01:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 30 Jul 2013 01:01:10 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4135FD@ESESSMB209.ericsson.se> References: <1375119910.76535.YahooMailNeo@web171302.mail.ir2.yahoo.com> <7594FB04B1934943A5C02806D1A2204B1C4132BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4135FD@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Jul 2013 10:01:10 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnDH6iSVsT6BYaPeFKlFSumirsJxNU/sDNuR5bxD9xZeHssyZMKXZPMQDgUdOAKi4wPre5E Cc: "public-webrtc@w3.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:01:43 -0000 >> The only we need is that peer-A tells peer-B about its tracks and peer-B= tells peer-A about its tracks. We don't have that with SDP. > > Well, the peers have to use SOMETHING to do that. Could you please explain it a bit more? If I am not wrong you insist on the fact that, *theorically*, if a device knows (by other means) the number of participants in a conference it can generate a SDP with so many m lines (as in the "solution 1" I told about). Then I recall: that is NOT possible in WebRTC. The API does not let me to add 8 m=3Daudio lines (all of them with a=3Drecvonly but one with a=3Dsendrec). It is not valid for me that SDP allows "magic". I am interested in which I can do with SDP *within WebRTC* via the "SDP-blob based API". Thanks. --=20 I=C3=B1aki Baz Castillo From ted.ietf@gmail.com Tue Jul 30 01:18:31 2013 Return-Path: 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 870E121E80E7 for ; Tue, 30 Jul 2013 01:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 IGjHYATHo1jw for ; Tue, 30 Jul 2013 01:18:22 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA4511E8123 for ; Tue, 30 Jul 2013 01:18:03 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id up14so3353774obb.39 for ; Tue, 30 Jul 2013 01:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+1y7/9JwyAQbKBGzmW4OdX45eAPQzwommeDp+hTnXQE=; b=vTnibLAfnzp+ReH821BhJ5VzyvyAwPmQDAF/iG8hZ/SmpARTzwBNUNxTPPa+vM1zjs CIwR3cGffsumcXj3cS1TezLv0nLlHM4IIL4/I4ybur/gqW8HNaL7OEJCJQebL39Z+Flg 5Nd25kT0HqcaMi8vCAmhK4NRNaE/WawoknfA1zamMvTWJM4GDnW9YrN1pY8V5wN2psAX cQgNLIET+xs79Zkl7n2sqXcp/PYb2Lx2OezpwrLLi6YIPWAHNqLHQBxPE1ayTEd65Rv6 b9rV1zuo1ZaxcX5fbDt1tQu905MROdS/DwAi/FCfTAkAz4Tr+nCz4aBVkSvRmSlNhWg4 jM+w== MIME-Version: 1.0 X-Received: by 10.50.134.9 with SMTP id pg9mr35759igb.29.1375172282761; Tue, 30 Jul 2013 01:18:02 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Tue, 30 Jul 2013 01:18:02 -0700 (PDT) Date: Tue, 30 Jul 2013 10:18:02 +0200 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7b41407e6b484604e2b63ffa Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: [rtcweb] Cross posting: Re: SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:18:31 -0000 --047d7b41407e6b484604e2b63ffa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howdy, We have asked that folks avoid cross-posting, in order to keep it easier for folks to follow a thread. Please keep this discussion on public-webrtc= . thanks, Ted Hardie On Tue, Jul 30, 2013 at 9:45 AM, I=F1aki Baz Castillo wrote= : > 2013/7/30 Silvia Pfeiffer : > > Since you seem to be doing a full mesh and you seem to be wanting to > > receive from everyone and be able to talk back to everyone, wouldn't > > this need to be 8 different SDP offers in a full mesh network rather > > than one SDP offer with 13 different m-lines? I don't follow how each > > of the recipients would pick the right m-line for themselves... > > > Silvia, I don't feel I am doing a full mesh, but something really > common, which is: > > - I contact, from my browser, to a conference server in which there is > an active conference with N participants. > > - I provide my audio and video tracks to the conference server. > > - The server provides me with N audio/video tracks belonging to N > participants. > > - I don't want to do a second SDP O/A round trip. > > Please, note that my browser has a signaling and a media session with > the conference server. This is, the endpoints are my browser and the > conference server. The fact that the conference server acts as a mixer > by joining all the participants changes nothing. The browser > establishes a single RTC session with the server. This is not an > exotic scenario at all. > > And no, I do not want to send 8 different SDP offers since I will > mantain just a single RTC session (with the conference server). All > the participants do the same, and the conference server is responsible > of taking all the tracks from participants and send them to all the > participants (via separate tracks). > > > I would like to hear the opinion of those in favour of SDP for WebRTC, > since what I am clearly stating is that SDP and Plan-Unified is *bad* > for this common scenario. > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b41407e6b484604e2b63ffa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howdy,

We have asked that folks avoid cross-posting, in order to kee= p it easier for folks to follow a thread.=A0 Please keep this discussion on= public-webrtc.

thanks,

Ted Hardie

On Tue, Jul 30, 2013 at 9:45 AM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:
2013/7/30 Silvia Pfeiffer <= silviapfeiffer1@gmail.com>:
> Since you seem to be doing a full mesh and you seem = to be wanting to
> receive from everyone and be able to talk back to everyone, wouldn'= ;t
> this need to be 8 different SDP offers in a full mesh network rather > than one SDP offer with 13 different m-lines? I don't follow how e= ach
> of the recipients would pick the right m-line for themselves...


Silvia, I don't feel I am doing a full mesh, but something really=
common, which is:

- I contact, from my browser, to a conference server in which there is
an active conference with N participants.

- I provide my audio and video tracks to the conference server.

- The server provides me with N audio/video tracks belonging to N participa= nts.

- I don't want to do a second SDP O/A round trip.

Please, note that my browser has a signaling and a media session with
the conference server. This is, the endpoints are my browser and the
conference server. The fact that the conference server acts as a mixer
by joining all the participants changes nothing. The browser
establishes a single RTC session with the server. This is not an
exotic scenario at all.

And no, I do not want to send 8 different SDP offers since I will
mantain just a single RTC session (with the conference server). All
the participants do the same, and the conference server is responsible
of taking all the tracks from participants and send them to all the
participants (via separate tracks).


I would like to hear the opinion of those in favour of SDP for WebRTC,
since what I am clearly stating is that SDP and Plan-Unified is *bad*
for this common scenario.


--
I=F1aki Baz Castillo
<ibc@aliax.net>
_____________________________= __________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b41407e6b484604e2b63ffa-- From radhika.r.roy.civ@mail.mil Tue Jul 30 04:23:49 2013 Return-Path: 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 4483111E81C4 for ; Tue, 30 Jul 2013 04:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 N-YTgMFqNZ+Q for ; Tue, 30 Jul 2013 04:23:43 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.13]) by ietfa.amsl.com (Postfix) with ESMTP id B72D511E81F3 for ; Tue, 30 Jul 2013 04:23:36 -0700 (PDT) Received: from UCOLHP3P.easf.csd.disa.mil (131.64.100.155) by edge-cols.mail.mil (131.64.100.13) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 30 Jul 2013 11:23:35 +0000 Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.43]) by UCOLHP3P.easf.csd.disa.mil ([131.64.100.155]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 11:23:34 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Silvia Pfeiffer Thread-Topic: [rtcweb] SDP is not suitable for WebRTC (UNCLASSIFIED) Thread-Index: AQHOjK50kFQA3ktZMU24WHKXTf6sAZl82EyAgAA7YjA= Date: Tue, 30 Jul 2013 11:23:32 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49B37A18@ucolhp9b.easf.csd.disa.mil> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0004_01CE8CF5.B07A3C00" MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Subject: Re: [rtcweb] SDP is not suitable for WebRTC (UNCLASSIFIED) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:23:49 -0000 ------=_NextPart_000_0004_01CE8CF5.B07A3C00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED Caveats: NONE I=C3=B1aki: Yes, the conference setup scenario is itself is restricted in a kind of = start-conference-arch, as if, it is the third party call setup in the = SIP-conf-scenario in your conf-flow. So, the discussions need to be confined based on this particular = conf-call-flow arch. Once we agree on this, we can then limit our = discussions with thiis particular case instead of making a general case. BR/Radhika -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of I=C3=B1aki Baz Castillo Sent: Tuesday, July 30, 2013 3:46 AM To: Silvia Pfeiffer Cc: rtcweb@ietf.org; public-webrtc@w3.org Subject: Re: [rtcweb] SDP is not suitable for WebRTC 2013/7/30 Silvia Pfeiffer : > Since you seem to be doing a full mesh and you seem to be wanting to=20 > receive from everyone and be able to talk back to everyone, wouldn't=20 > this need to be 8 different SDP offers in a full mesh network rather=20 > than one SDP offer with 13 different m-lines? I don't follow how each=20 > of the recipients would pick the right m-line for themselves... Silvia, I don't feel I am doing a full mesh, but something really = common, which is: - I contact, from my browser, to a conference server in which there is = an active conference with N participants. - I provide my audio and video tracks to the conference server. - The server provides me with N audio/video tracks belonging to N = participants. - I don't want to do a second SDP O/A round trip. Please, note that my browser has a signaling and a media session with = the conference server. This is, the endpoints are my browser and the = conference server. The fact that the conference server acts as a mixer = by joining all the participants changes nothing. The browser establishes = a single RTC session with the server. This is not an exotic scenario at = all. And no, I do not want to send 8 different SDP offers since I will = mantain just a single RTC session (with the conference server). All the = participants do the same, and the conference server is responsible of = taking all the tracks from participants and send them to all the = participants (via separate tracks). I would like to hear the opinion of those in favour of SDP for WebRTC, = since what I am clearly stating is that SDP and Plan-Unified is *bad* = for this common scenario. -- I=C3=B1aki Baz Castillo _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0004_01CE8CF5.B07A3C00 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzA3MzAxMTIzMjlaMCMGCSqGSIb3DQEJBDEWBBSaLOtjlqcdvo9WDgO9i89k D8O68TBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAGoflg2Q6dSGGvvOZuDfIVKh95/X2eHwYr18is3/4ZaeBAPb6s8SsuASnCRRTjR75PZA UOGuKq1htlWYNOnlok0C6YTI9WMqjeZgNxnFWCWOfjcdkeLJOn1lFr7xp8+SkW7pYa8ER86Ogwze jEx/lIWoCZG7udTSy6cR4f0U1c14w6STiSN/AzFbEJJ1lVN8VdKScVz1cf+9owRgY5LVW4IiOCTn 1dDpYNWg9XulZzdBd0/snr61NLKKk1oua7E8rUrom8ogradlyzN3ye2UreH4n5sRgysW34htQuKQ vCxDTEzZEpbD4NmXvuNB+wHmEmavrDDhUBltL7r/bhM4474AAAAAAAA= ------=_NextPart_000_0004_01CE8CF5.B07A3C00-- From richard.ejzak@alcatel-lucent.com Tue Jul 30 04:45:45 2013 Return-Path: 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 478E621F99D0; Tue, 30 Jul 2013 04:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Gm0fvBbDE3Z8; Tue, 30 Jul 2013 04:45:39 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 89E8B21F9E4F; Tue, 30 Jul 2013 04:45:39 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6UBjall017779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2013 06:45:36 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r6UBjaVr018744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 07:45:36 -0400 Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.98]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 30 Jul 2013 07:45:36 -0400 From: "Ejzak, Richard P (Richard)" To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "dispatch@ietf.org" Thread-Topic: [MMUSIC] [rtcweb] [dispatch] bar BOF on msrp over DataChannels Thread-Index: AQHOjRpNvvdmZT6rGEqXeTPhf185Ug== Date: Tue, 30 Jul 2013 11:45:35 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F3D844196@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412CD3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412D3F@ESESSMB209.ericsson.se> <51F78002.80102@alvestrand.no> In-Reply-To: <51F78002.80102@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [rtcweb] [MMUSIC] [dispatch] bar BOF on msrp over DataChannels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:45:45 -0000 QXMganVzdCBtZW50aW9uZWQgaW4gbW11c2ljLCB3ZSBhcmUgb3JnYW5pemluZyBhIGJhciBCT0Yg Zm9yIFRodXJzZGF5IGF0IDY6MzAgUE0gaW4gdGhlIE1hcmxlbmUgQmFyIHRvIGRpc2N1c3MgU0RQ IGFzcGVjdHMgaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFy Y29uLW1zcnAtb3Zlci13ZWJydGMtZGF0YS1jaGFubmVscy0wMC50eHQuICBJbiBwYXJ0aWN1bGFy LCB0aGUgZHJhZnQgaW5jbHVkZXMgU0RQIHByb2NlZHVyZXMgdG8gbmVnb3RpYXRlIHRoZSB1c2Ug b2YgYW55IHN1Yi1wcm90b2NvbCAoZS5nLiwgbXNycCwgYmZjcCwgdDE0MCkgb3ZlciBEYXRhQ2hh bm5lbHMgKGZvciBzdWItcHJvdG9jb2xzIHRoYXQgbm9ybWFsbHkgdXNlIFNEUCBuZWdvdGlhdGlv biBmb3Igb3RoZXIgdHJhbnNwb3J0IG9wdGlvbnMpLiAgU29tZSBtaW5pbWFsIGFkZGl0aW9uYWwg c3ViLXByb3RvY29sIHNwZWNpZmljIHByb2NlZHVyZXMgbWlnaHQgYWxzbyBuZWVkIHRvIGJlIHNw ZWNpZmllZC4gIFRoZSBkcmFmdCBhbHNvIGluY2x1ZGVzIG1zcnAtc3BlY2lmaWMgcHJvY2VkdXJl cyBuZWVkZWQgZm9yIHRoZSB0cmFuc3BvcnQgb2YgbXNycCBvdmVyIERhdGFDaGFubmVscy4NCg0K VGhpcyBwcm9wb3NhbCBpcyBpbnRlbmRlZCB0byBjb21wbGVtZW50IHRoZSBjdXJyZW50IERhdGFD aGFubmVsIHByb2NlZHVyZXMgd2l0aG91dCByZXF1aXJpbmcgYW55IGJyb3dzZXIgc3VwcG9ydCwg d2hpY2ggaXMgd2h5IHRoaXMgd29yayBoYXMgbm90IGJlZW4gcmFpc2VkIGRpcmVjdGx5IGluIHJ0 Y3dlYi4NCg0KUGxlYXNlIGpvaW4gdXMgYXQgdGhlIE1hcmxlbmUgYmFyIG9yIGxldCBtZSBrbm93 IGlmIHlvdSBhcmUgaW50ZXJlc3RlZCBidXQgdW5hYmxlIHRvIHBhcnRpY2lwYXRlLg0KDQpUaGFu a3MsDQpSaWNoYXJkDQo= From ibc@aliax.net Tue Jul 30 06:11:43 2013 Return-Path: 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 0DF3B21F8436 for ; Tue, 30 Jul 2013 06:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 0SZRRLzJhfzU for ; Tue, 30 Jul 2013 06:11:38 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id DAF7521E80C0 for ; Tue, 30 Jul 2013 06:11:37 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id b10so1606764qen.34 for ; Tue, 30 Jul 2013 06:11:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=EMdfIkHxCduGvw/2aAkBUiI9u1GCfKc1irlfWR6uCQ0=; b=V11A6fNfeoIg8yqCqkmYILURJwUpkroMBXe5DwLjXsJmwfnjpRm7eItGiwLl9uNETw oqtWeEG1aYAyf5E0zrQKDqmGpocRSLFqL5QJ0+KJXUPafYOGI5RRHnLkGuhzBpQp1ZWx 6xSkfW1hGDGvSMwxaE8SUB8riCv0jEoLy1ZXsakwqwPwQDUu2fq0RtE5Y2DceAhNzBU0 F397udfn5XU3yD/0N1p7aGvPThP0nzvbxIfbqF5jhJPfQlnGjeaXtCPNkZTkEfcSfokG j41n0+5SQbpsQA2HrTHqKa7MSzUDPGdGwr1F86P54t0CQFFtcp7qdWLlzhleIZmMcTOu LANw== X-Received: by 10.229.206.2 with SMTP id fs2mr7215024qcb.68.1375189896090; Tue, 30 Jul 2013 06:11:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 30 Jul 2013 06:11:16 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Jul 2013 15:11:16 +0200 Message-ID: To: "rtcweb@ietf.org" , draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl8FYchDASa0WjXKQ+FOzo65zT1XR6TACP1nPxFQdKg+XLY8bd6NpZP0FO9H1q6zbMfjYgK Subject: [rtcweb] Requesting a new use case / requirement for draft-ietf-rtcweb-use-cases-and-requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 13:11:43 -0000 Hi, I would like to request a new use case / requirement for WebRTC to be included in draft-ietf-rtcweb-use-cases-and-requirements: Contacting a conference server --------------------------------------------- The browser must be able to generate a media offer to be sent to a conference server, by providing its audio and video information (media tracks to be sent by the browser), and the conference server must be able to reply a single response accepting the offer and indicating the browser all the media tracks from other participants it will send to it. This must be possible without requiring a new media negotiation round trip, and without requiring that the browser knows the number of participants in the conference before contacting it. Note that in this scenario the browser is the session initiator and thus the media description offerer, while the conference server provides the media description answer. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ted.ietf@gmail.com Tue Jul 30 07:16:23 2013 Return-Path: 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 16EB821F9CC8 for ; Tue, 30 Jul 2013 07:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 alMX8o5IuB0a for ; Tue, 30 Jul 2013 07:16:22 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id A33AF21F9CC2 for ; Tue, 30 Jul 2013 07:16:16 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k14so16039547oag.40 for ; Tue, 30 Jul 2013 07:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OKjZlum8PSotxOnS4IBS0LDwNZAIxA75BswloVmWc3o=; b=x1VbzFdQieSWsOqTPjruEsOdJk1m05VKEx5fKPuViLe92gJXKQX8jSrcdHLxzLQLY2 zeyoXktWDSplnDomVnrAOXgFejWmjOArzdKVWdzxSNXqXA6SPOhaLin32cVJJKE8rShm m/OFGig50a2nVBCSs51SEA5/pNQi9fE+dqoWSYLG58h9W9LFHDSgj4C3RfHDn6vmy0Ef h4vwm1DsOmAoJGXi8k/VYkqnAbPMqcYQpIFqdeoc2K3bivS6fLuB/AMQjVIUz7y6VQSX HDpvJHwhbRqV53Co0hsHM3U2OCVx6KQHFM4hceezDSdZ/JEO4shViALNDIIXD2/WwVTL tY0A== MIME-Version: 1.0 X-Received: by 10.43.67.73 with SMTP id xt9mr21808861icb.99.1375193772391; Tue, 30 Jul 2013 07:16:12 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Tue, 30 Jul 2013 07:16:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jul 2013 16:16:12 +0200 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=089e015370964d0af004e2bb40ae Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org Subject: Re: [rtcweb] Requesting a new use case / requirement for draft-ietf-rtcweb-use-cases-and-requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:16:23 -0000 --089e015370964d0af004e2bb40ae Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This seems to conflate what you want the service to do and how you believe it ought to operate. The core use case appears to be a variant of the "Multiparty video communication" in section 4.2.10.1. If I understand correctly, this variant retains the browser behavior in respect to rendering of peer media, but gets all the audio and video streams from a single peer (the conferencing server). This text: "The conference server must be able to reply a single response accepting the offer and indicating the browser all the media tracks from other participants it will send to it. This must be possible without requiring a new media negotiation round trip, and without requiring that the browser knows the number of participants in the conference before contacting it." is not appropriate for a use case. It's a proposed constraint on the solution, rather than a description of the use. regards, Ted Hardie On Tue, Jul 30, 2013 at 3:11 PM, I=F1aki Baz Castillo wrote= : > Hi, I would like to request a new use case / requirement for WebRTC to > be included in draft-ietf-rtcweb-use-cases-and-requirements: > > > > > > Contacting a conference server > --------------------------------------------- > > The browser must be able to generate a media offer to be sent to a > conference server, by providing its audio and video information (media > tracks to be sent by the browser), and the conference server must be > able to reply a single response accepting the offer and indicating the > browser all the media tracks from other participants it will send to > it. This must be possible without requiring a new media negotiation > round trip, and without requiring that the browser knows the number of > participants in the conference before contacting it. > > Note that in this scenario the browser is the session initiator and > thus the media description offerer, while the conference server > provides the media description answer. > > > > > Thanks a lot. > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e015370964d0af004e2bb40ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This seems to conflate what you want the service to do and how you believe = it ought to operate.=A0 The core use case appears to be a variant of the &q= uot;Multiparty video communication" in secti= on 4.2.10.1.=A0 If I understand correctly, this variant retains the browser= behavior in respect to rendering of peer media, but gets all the audio and= video streams from a single peer (the conferencing server).=A0

This text:

"The conference server must be able to reply a s= ingle response accepting the offer and indicating the browser all the media= tracks from other participants it will send to it. This must be possible w= ithout requiring a new media negotiation round trip, and without requiring = that the browser knows the number of participants in the conference before = contacting it."

is not appropriate for a use case.=A0 It's a proposed constraint on= the solution, rather than a description of the use.

regards,
Ted Hardie


On Tue, Jul 30, 2013 at 3= :11 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
Hi, I would like to request a new use case /= requirement for WebRTC to
be included in draft-ietf-rtcweb-use-cases-and-requirements:





Contacting a conference server
---------------------------------------------

The browser must be able to generate a media offer to be sent to a
conference server, by providing its audio and video information (media
tracks to be sent by the browser), and the conference server must be
able to reply a single response accepting the offer and indicating the
browser all the media tracks from other participants it will send to
it. This must be possible without requiring a new media negotiation
round trip, and without requiring that the browser knows the number of
participants in the conference before contacting it.

Note that in this scenario the browser is the session initiator and
thus the media description offerer, while the conference server
provides the media description answer.




Thanks a lot.


--
I=F1aki Baz Castillo
<ibc@aliax.net>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e015370964d0af004e2bb40ae-- From ibc@aliax.net Tue Jul 30 08:06:32 2013 Return-Path: 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 9C33721F9A13 for ; Tue, 30 Jul 2013 08:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 CZPla7dNHbAV for ; Tue, 30 Jul 2013 08:06:16 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB9D11E81FD for ; Tue, 30 Jul 2013 08:06:12 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so3127030qeb.29 for ; Tue, 30 Jul 2013 08:06:11 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=+fxz/qNxABy6rxckdh5kCF2INpPTE/D5XcY471M23Rk=; b=kT+GqDa/FlSSVbPQgwV1TwEFRk4d9kTxHBL4AcSjkw1giKG1us7n6BZ8dPiIcivhS6 0ExenfLpoXJ8O6PzBOUIeGypeCyo/ATcN3o1pRwsvdIzbDD/izWFDRrPmkkzCoQQUvvz Sq2r1Nf6Ws3SBCbowcyL2C7VjmlA2XXsH7v/koWHHj3eAwOomqdMwbI0lUMOAvkgYHLV z7GP3S/v7uQa2jBVmXu7FtbqLu5mOAri14YBNklaQ2VhRelUiNJKHyDkxPPojsA+LTli 5aL7FIU1GGEY7+7t5bHgWb+p4FnLYqrohSN6JfokzI1r7guzm7FI0tabHVNf+c7ZwbMp RqDQ== X-Received: by 10.224.182.79 with SMTP id cb15mr79607274qab.48.1375196771096; Tue, 30 Jul 2013 08:06:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 30 Jul 2013 08:05:50 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 30 Jul 2013 17:05:50 +0200 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk8436BFEjpcXy5rPzAR/7So+7j0sQxf+L6dCO7a4f94WI8V1jZ6qgyTlaWbiTJqoFIRrOn Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-use-cases-and-requirements Subject: Re: [rtcweb] Requesting a new use case / requirement for draft-ietf-rtcweb-use-cases-and-requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:06:32 -0000 2013/7/30 Ted Hardie : > "The conference server must be able to reply a single response accepting = the > offer and indicating the browser all the media tracks from other > participants it will send to it. This must be possible without requiring = a > new media negotiation round trip, and without requiring that the browser > knows the number of participants in the conference before contacting it." > > is not appropriate for a use case. It's a proposed constraint on the > solution, rather than a description of the use. Hi Ted, I agree that the above is not an use case but a requirement. But in contrast to what you say, I don't consider it a "constrain". Instead I consider a constrain the current SDP O/A mandate which does not let me implementing the above (the opposite is not true). Should I request a new "requirement" for the draft instead of a new use cas= e? Best regards. --=20 I=C3=B1aki Baz Castillo From partha@parthasarathi.co.in Tue Jul 30 09:47:22 2013 Return-Path: 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 3146A21F9339 for ; Tue, 30 Jul 2013 09:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.174 X-Spam-Level: X-Spam-Status: No, score=-1.174 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_50=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 8bTyb1oIjrv3 for ; Tue, 30 Jul 2013 09:47:17 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id E275211E8227 for ; Tue, 30 Jul 2013 09:44:15 -0700 (PDT) Received: from userPC (unknown [122.179.49.243]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id C36D0868A28 for ; Tue, 30 Jul 2013 16:44:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1375202644; bh=k5f6MFfE74tJ0fcxDvEsOrwfIRQFjqQLcERYxUMQ1nc=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=UHlVBabiRpBbJFu4IMN7Q5Tx/M1EFHSKWw/B0xzmwoV0GOMTr1oIzo8WOS162OuED WM6oTNE5uWU8SbZLAcRW9YKA+GEEuv2g4UVoq/islLbtWx6xI2Juwul6uvTEYt6yKc UzR8da6tbkGMKIRXGHJRmEQMMHFvqC1k9jIIEgqM= From: "Parthasarathi R" To: Date: Tue, 30 Jul 2013 22:13:57 +0530 Message-ID: <000101ce8d43$fe654ce0$fb2fe6a0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6NQ/ubADig5S2PTBuFLzrFgkFTnQ== Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0204.51F7ED54.0147, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.153 Subject: [rtcweb] Offer event handling for Pranswer state missing in JSEP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 16:47:22 -0000 Hi all, In JSEP state machine, OFFER event is not possible to be handled at Local-Pranswer, Remote-Pranswer state. OFFER event is required in local-pranswer for multiple offer/answer handling like BUNDLE, ICE negotiations. The example callflow for early-dialog with multiple offer/answer handling is available at Sec 5.2 of draft-partha-rtcweb-jsep-sip-00. It is open item in JSEP. Thanks Partha From Ruediger.Geib@telekom.de Wed Jul 31 01:12:01 2013 Return-Path: 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 AF8C721E812A; Wed, 31 Jul 2013 01:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 2FPWBLefvPST; Wed, 31 Jul 2013 01:11:45 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32821F9E9E; Wed, 31 Jul 2013 01:11:19 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 31 Jul 2013 10:11:07 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 31 Jul 2013 10:11:07 +0200 From: To: Date: Wed, 31 Jul 2013 10:11:05 +0200 Thread-Topic: [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) Thread-Index: Ac5+myIfjYPS5jaWQ0qZ0s3PmyqMpwPJs6TA Message-ID: References: <20130710180147.GA614@cisco.com> <20130712005930.GB30036@cisco.com> In-Reply-To: <20130712005930.GB30036@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 31 Jul 2013 01:59:54 -0700 Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:12:05 -0000 Toerless, discussion seems to conclude with: - fairness must be enforced if senders don't set DSCPs according to the glo= bal fairness scheme. - video applications have a hard time setting DSCPs anyway due to a missing= API. - ECN is not meant to indicate drop priorities and offers an insufficient number of states. It might be easier to use a single PHB/DSCP and add PCN like ECN. In an e2e= mode with receivers giving PCN congestion feedback to senders. My definiti= on of PCN would be "rate control on a congested link" (rather than admissio= n control and traffic termination as applied by the WG - I've been involved= in the WGs work). This should result in: - avoidance of sudden overload in that class (no burst drops) - rate adaption of senders if congestion is pending - a simpler design as compared to what you and Ken discussed I'm going to drop another message soon. Regards, Ruediger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of T= oerless Eckert (eckert) Sent: Friday, July 12, 2013 3:00 AM To: Dave Taht Cc: rmcat@ietf.org; rtcweb@ietf.org; tsvwg@ietf.org Subject: Re: [tsvwg] Using intelligent dropping to improve video quality un= der congestion (draft-lai-tsvwg-normalizer-00.txt) On Wed, Jul 10, 2013 at 12:02:26PM -0700, Dave Taht wrote: > I've begun to look at webrtc of late in the context of fq_codel. > > One thing that might work would be ECN marking important frames and > not ECN marking others. True. But i think there are at least 3 layers of priority that would really be great to have: really important packet (long term reference frames), "normal" packets, and low-proirity-packets (eg: discardable P). And ECN could only do two. Most of the time when you would want intelligent dropping, your drop rate should be fairly low, eg< 20% instantaneous within the queue. If you can do discardable P-frames it's of course best to drop those first. Only when you instantaneously have really big bursts would you want to drop "normal" packets and refrain to protection really important packets. This does work really well with different queue-length (or WRED profiles). If you only had two priorities (via ECN) it's hard to say how you would best assign these two priorities to at least those three priority levels. > Problem overall is that ecn can be gamed and is largely not > enabled, and so on... Well. The gaming could be inhibited exactly by this draft because it would try to guarantee the same amount of drops on a per-flow or "class" basis, so if you're trying to game the system, you would be put into your own class and would still see the same amount of drops as other flows. Well, the main issue is really to redesignate ECN for a different semantic than what it has today. And indicating packet priority is just not quite the same as congestion feedback. > In the case of the fq_codel algorithm I can see a "delayed drop" > mechanism happening, > where upon deciding to drop, it could defer a drop up to a few packets > based on the classification > of the packet, say 3 packets at most. Since flows are already > identified, this is kind of easy > by adding another state variable... Yes, this is all quite interesting. We also played around with droppping during enqueuing vs. during dequeuing, so there are a bunch of things that could optimize intelligent dropping if you can build a more intelligent queue. [...] > > So I can see trying to utilize the AF markings as you describe in your > draft in codel's > drop decision. While this is also subject to being gamed, the > disincentives are slight. Lets separate the marking from the mechanism to inhibit gaming. This draft really is about the latter, and the marking described with AF is really just an example. Yes, it would be lovely to agree on markings too. > And what codel depends on is a definition of "TCP friendly". That if a > stream is not going to behave in a tcp friendly manner, then an entirely > different strategy for such flows seems necessary, and glomming on some > additional state isn't going to be the right thing. Who stood up at RMCAT some time back and claimed to have worked for > 10 years on TCP and declared TCP not self friendly to itself, so RMCAT shouldn't bother ? ;-)) Kidding aside: Intelligent dropping IMHO makes perfect sense when being applied to RT traffic sharing a queue friendly with TCP. And intelligent dropping can then still improve the performance. I am pretty positive though that RMCAT traffic in general will behave better and get lower delay and more video-appropriate loss if it can have its own queue. Primarily because it will just take decates to root out all the bad TCP traffic. I don't think that the strategies if you do or if you don't share the queue with TCP would be fundamentally be different. > a) how well can it work in routers to shift packet drops to low-prio pack= ets > > I guess where I fall apart here is how to shift the encoders to send thin= ner > streams at any level of packet drop. Video codec coders are known to be able to do crazy cool things. There are a bunch of known mechanisms and probably more proprietary ones. > I'd be interested in specific codecs, example video streams, and test > scripts to try and fiddle with this, as well as viable metrics. Sure. Best done in person. If we're going to be at the WG for this, we can talk on the side how we've been doing this. Cheers Toerless > > Thanks! > > Toerless > > > > In-Reply-To: > > > > On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote: > >> Hi all, > >> > >> We have submitted a new Internet draft to describe a Normalization Mar= ker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal o= f NM deployment is to create a new incentive for video encoders to generate= more discardable packets when using AF PHB in DIffServ. We are looking for= ward to your review comments. > >> > >> Best regards, > >> CJ > >> > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, February 08, 2013 6:25 PM > >> To: Cheng-Jia Lai (chelai) > >> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (ecke= rt); Fred Yip (fyip) > >> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.tx= t > >> > >> > >> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt > >> has been successfully submitted by Cheng-Jia Lai and posted to the > >> IETF repository. > >> > >> Filename: draft-lai-tsvwg-normalizer > >> Revision: 00 > >> Title: Normalization Marker for AF PHB Group in DiffSe= rv > >> Creation date: 2013-02-08 > >> WG ID: Individual Submission > >> Number of pages: 15 > >> URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-n= ormalizer-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-norma= lizer > >> Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer= -00 > >> > >> > >> Abstract: > >> This memo describes a Normalization Marker (NM) at DiffServ (DS) > >> nodes to normalize the distribution of DS codepoint (DSCP) markings > >> for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is > >> useful for traffic conditioning with Active Queue Management (AQM) > >> when the AF PHB group is deployed for multimedia service classes th= at > >> carry video packets with advanced codec technologies. Using NM can > >> offer an incentive that is however missing in today's ecosystem of > >> practical deployment, i.e., when congestion occurs in the AF PHB > >> group, the network should allow a video codec to benefit from its > >> effort of generating finer layers of intra-flow precedence (IFP) wi= th > >> discardable packets in a more balanced distribution. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > Cisco NSSTG Systems & Technology Architecture > > SDN: Let me play with the network, mommy! > > > > > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From Ruediger.Geib@telekom.de Wed Jul 31 01:28:44 2013 Return-Path: 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 91B5D21E8055; Wed, 31 Jul 2013 01:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 Zx6gRZKc-jTg; Wed, 31 Jul 2013 01:28:17 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1829021F9E96; Wed, 31 Jul 2013 01:26:51 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 31 Jul 2013 10:26:50 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 31 Jul 2013 10:26:49 +0200 From: To: Date: Wed, 31 Jul 2013 10:26:48 +0200 Thread-Topic: [tsvwg] Using intelligent dropping to improve video.....adding admission control? Thread-Index: Ac5+myIfjYPS5jaWQ0qZ0s3PmyqMpwPKmREw Message-ID: References: <20130710180147.GA614@cisco.com> <20130712005930.GB30036@cisco.com> In-Reply-To: <20130712005930.GB30036@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 31 Jul 2013 02:00:04 -0700 Cc: rmcat@ietf.org, rtcweb@ietf.org, tsvwg@ietf.org Subject: Re: [rtcweb] [tsvwg] Using intelligent dropping to improve video.....adding admission control? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:28:45 -0000 Toerless, prior to setting up a new call, some kind of available bandwidth measuremen= t or indication might be added. This isn't part of your draft. But an addit= ional video stream may cause congestion on a bottleneck. Measurement based admission control has been controversial so far. If used,= the main point is to use a measurement class sharing the same queue as the= traffic to be admitted, but having a higher drop probability. - PCN is an option, but requires a new marking behaviour (threshold marker). End to end PCN as mentioned in another email. - Using AF41 for admitted traffic and AF42 to perform measurements is an option to me, both should support ECN marking (AF42 seeing the higher marking and drop probability). As marked packets indicating an issue can be interpreted by routers along a= path, while packets dropped earlier elsewhere can't be, I prefer marking t= o dropping. I also think, it is easier to detect packet marks than delay va= riation measurements in routers, if it is about detecting congestion. Take the above as an example. I used a separate thread as this isn't part o= f your draft an I accept if this shouldn't be discussed in the context of t= his draft. It fit's well to the RTCWeb QoS discussion though, I think. Regards, Ruediger From ted.ietf@gmail.com Wed Jul 31 06:52:00 2013 Return-Path: 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 E316021F9CCA for ; Wed, 31 Jul 2013 06:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 mosauRybLeQp for ; Wed, 31 Jul 2013 06:51:59 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 92FF621F9CC3 for ; Wed, 31 Jul 2013 06:51:57 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i4so1570591oah.9 for ; Wed, 31 Jul 2013 06:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=GHeDgMko7dpQu++iRedqtcV/MGM7yfSG95sEX2PUcCM=; b=D1l4ripMdgv0YAMiAVd32Wp8Rr9k9QwTAbSrriA9TPpXYnFzcZfo9R88TlhAeahgrt txLIpLMdyC0lB2c0EXXKnNaBgw8Lfd5posvqY9W6JU0LVli/NWScZ1RdkVRnumy6JOkW lK+R+zMJaxvLXVSLbUPTamrQvdxGirM8YmDmKNM/vmB0GgyY01TDJxVYhQcLEfcrUH11 AQqO3k5IZgJkqWNhmQnW0Bary2y+Ssd13h7NnvsvJ2zDhbcngeKRcCWLtqdPv4UMYhIn cZNGTldR/k7rzRZk23jTeebZk4qHwTNdqs1l2WEuUWXyTG3F/R877v5irWlcM6/8y6ZE xJng== MIME-Version: 1.0 X-Received: by 10.50.164.167 with SMTP id yr7mr700618igb.22.1375278717129; Wed, 31 Jul 2013 06:51:57 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Wed, 31 Jul 2013 06:51:57 -0700 (PDT) Date: Wed, 31 Jul 2013 15:51:57 +0200 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=089e0122a7fc66dbb504e2cf07b9 Cc: Cullen Jennings Subject: [rtcweb] Reminder: scribes needed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:52:00 -0000 --089e0122a7fc66dbb504e2cf07b9 Content-Type: text/plain; charset=ISO-8859-1 We still need scribes for the meeting tomorrow; please volunteer if you can do that for us. thanks, Ted Hardie --089e0122a7fc66dbb504e2cf07b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We still need scribes for the meeting tomorrow; please volunteer if you can= do that for us.=A0

thanks,

Ted Hardie
--089e0122a7fc66dbb504e2cf07b9-- From stpeter@stpeter.im Wed Jul 31 06:58:08 2013 Return-Path: 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 471B921F9D6F for ; Wed, 31 Jul 2013 06:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 AJz2hvZPRFfv for ; Wed, 31 Jul 2013 06:58:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEBA21F8475 for ; Wed, 31 Jul 2013 06:57:52 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5CE4640046; Wed, 31 Jul 2013 08:00:06 -0600 (MDT) Message-ID: <51F917DD.1060402@stpeter.im> Date: Wed, 31 Jul 2013 15:57:49 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Reminder: scribes needed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:58:08 -0000 On 7/31/13 3:51 PM, Ted Hardie wrote: > We still need scribes for the meeting tomorrow; please volunteer if you > can do that for us. Do you need minute takers, jabber relays, or both? (And yes, we need to define these roles more clearly...) Peter -- Peter Saint-Andre https://stpeter.im/ From ted.ietf@gmail.com Wed Jul 31 07:01:56 2013 Return-Path: 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 2736421F96DA for ; Wed, 31 Jul 2013 07:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, 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 WRy6IED1eRGF for ; Wed, 31 Jul 2013 07:01:55 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EB9F121F9BB1 for ; Wed, 31 Jul 2013 07:01:30 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id g12so1081962oah.34 for ; Wed, 31 Jul 2013 07:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j9oKTxRXZWWJeRR+Ozcae6xsP2OuerUBpybAP6kFKCU=; b=AfPCeO/WlQ95FDiBh/0LNDAAsCxjXA2NTcWPHRDB4+Wr23dg5YrxOM2oeezRW37iiS RtWkofhhcvlr7wsN8Gz+1M1rV0pmnVnD+H+MN3KUDMpNPQ9iYmRYvIvw11cVoHIvVPT6 sZpC1AeT/cw5l/4dSoyXfsdNXChB8v08yP3DTt7zL7vnAveF3Da1NdbZu0zn+E3gobAm hD+LxjilFEDPX0UGYOd/BcrR7/oZoIUoaNNkPEjD+0QnmqBsaVqPF9CRwAeGcDsl09Hn BIby4MTGW0NDVnIwJ2+CnCBEGi4hVjVWpu9yKv18b8KAVjmk8yKd0vmuSbzB/FLRtyZD lWNg== MIME-Version: 1.0 X-Received: by 10.42.52.6 with SMTP id h6mr22492323icg.5.1375279290466; Wed, 31 Jul 2013 07:01:30 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Wed, 31 Jul 2013 07:01:30 -0700 (PDT) In-Reply-To: <51F917DD.1060402@stpeter.im> References: <51F917DD.1060402@stpeter.im> Date: Wed, 31 Jul 2013 16:01:30 +0200 Message-ID: From: Ted Hardie To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=20cf3036361f93483004e2cf2955 Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] Reminder: scribes needed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:01:56 -0000 --20cf3036361f93483004e2cf2955 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 31, 2013 at 3:57 PM, Peter Saint-Andre wrote: > On 7/31/13 3:51 PM, Ted Hardie wrote: > > We still need scribes for the meeting tomorrow; please volunteer if you > > can do that for us. > > Do you need minute takers, jabber relays, or both? > > Most urgently minute takers (which are sometimes called "scribes"). It is somewhat easier for the chairs to follow the jabber channel and, honestly, easier to press someone into service for that role, since it requires relay rather than writing. If someone can actually scribe *into* the jabber channel, that would be great, but we have meetecho as a fall back. Ted > (And yes, we need to define these roles more clearly...) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > --20cf3036361f93483004e2cf2955 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2013 at 3:57 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 7/31/13 3:51 PM, Ted Hardie wrote:
> We still need scribes for the meeting tomorrow; please volunteer if yo= u
> can do that for us.

Do you need minute takers, jabber relays, or both?

Most urgently minute takers (which are sometimes call= ed "scribes").=A0 It is somewhat easier for the chairs to follow = the jabber channel and, honestly, easier to press someone into service for = that role, since it requires relay rather than writing.=A0 If someone can a= ctually scribe *into* the jabber channel, that would be great, but we have = meetecho as a fall back.

Ted

=A0
(And yes, we need to define these roles more clearly...)

Peter

--
Peter Saint-Andre
https://stpeter.im/


--20cf3036361f93483004e2cf2955-- From mzanaty@cisco.com Wed Jul 31 08:12:11 2013 Return-Path: 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 3B0D321F9B53; Wed, 31 Jul 2013 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 crxvJhCYbkC6; Wed, 31 Jul 2013 08:12:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 14F3021F9B5B; Wed, 31 Jul 2013 08:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2567; q=dns/txt; s=iport; t=1375283523; x=1376493123; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vGBY5Jhpd5WRoEd+yQYLrG/ATVpelP2Al+Fq9xjb2BM=; b=jG9gYusNqdzf/NyougxhmhLaLJfSduNk+p7afyeRbcvBS4+uFmzVVnjT vsf4kxVOeljSHBDuW8I4npvqyxkDvyO5iqLQXZ2GqrBd+FWRxl2yJxqPV 13NPYt5983I8kl4oHzMRK7puBqv+/lmTlASIcquVrUeGhUZVSbXvHEdYB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAJgo+VGtJXG8/2dsb2JhbABRCoMGNVC+HYEYFnSCJAEBAQR3AgwEAgEIEQMBAgsZCzIdCAIEDgUIAYgHDLhxjkWBETEHBoMScwOIcpAWkCSBW4E5gio X-IronPort-AV: E=Sophos;i="4.89,788,1367971200"; d="scan'208";a="241789237" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2013 15:12:02 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6VFC2tU001532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 15:12:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 10:12:02 -0500 From: "Mo Zanaty (mzanaty)" To: Adam Fineberg Thread-Topic: [avtext] [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt Thread-Index: AQHOiJCjF97CHVLHtESLPGspt4xmi5l0Hkhg Date: Wed, 31 Jul 2013 15:12:01 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D4C75F3@xmb-rcd-x14.cisco.com> References: , <51EEA709.2020009@vline.me> <51F00A02.3060204@vline.me> In-Reply-To: <51F00A02.3060204@vline.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.165.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avtext@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:12:11 -0000 Hi Adam, Why do you include PictureID? I can understand how the "Y" bit for base lay= er sync can be useful to include. But how does including PictureID help ide= ntify temporal layers? Regards, Mo ________________________________________ Date: Wed, 17 Jul 2013 17:09:46 -0700 From: fineberg@vline.me To: rtcweb@ietf.org Subject: [rtcweb] Fwd: New Version Notification for draft-fineberg-avtext-t= emporal-layer-ext-00.txt Hi, I'm working on WebRTC services and have found that while developing service= s that forward VP8 video streams if we want to take advantage of the VP8 te= mporal scaling we must get the temporal layer information from the RTP head= er which requires us to decrypt the SRTP packets. This is undesirable both = because the middle-box needs to have access to the keys as well as the beca= use of the added overhead of the decrypt/encrypt cycle. This draft proposes= an RTP header extension that will allow us to use the VP8 temporal layer i= nformation included in the header extension and therefore do forwarding wit= hout SRTP decryption. Comments welcome. Regards, Adam Fineberg fineberg at vline.com -------- Original Message --------=20 Subject: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.tx= t Date: Tue, 09 Jul 2013 10:02:05 -0700 From: internet-drafts at ietf.org To: Adam Fineberg=A0 A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt has been successfully submitted by Adam Fineberg and posted to the IETF repository. Filename: draft-fineberg-avtext-temporal-layer-ext Revision: 00 Title: A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temp= oral Layer Information Creation date: 2013-07-08 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fineberg-avtext-= temporal-layer-ext-00.txt Status: http://datatracker.ietf.org/doc/draft-fineberg-avtext-temp= oral-layer-ext Htmlized: http://tools.ietf.org/html/draft-fineberg-avtext-temporal-= layer-ext-00 Abstract: This document defines a mechanism by which packets of Real-Time Tranport Protocol (RTP) video streams encoded with the VP8 codec can indicate, in an RTP header extension, the temporal layer information about the frame encoded in the RTP packet. This information can be used in a middlebox performing bandwidth management of streams without requiring it to decrypt the streams. --=20 Regards, Adam